comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » idlwave segfault
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
idlwave segfault [message #69329] Tue, 05 January 2010 11:06 Go to next message
Bruce Bowler is currently offline  Bruce Bowler
Messages: 128
Registered: September 1998
Senior Member
I'm pretty sure I've seen this mentioned before but google isn't helping
me find it if I'm correct...

I'm running Fedora 10, Emacs 22.3.1 and idlwave 6.1_em22 (all "defaults"
for F10, as far as I know).

When I try to start an IDL shell from within emacs (via C-c C-s), I get a
few messages that scroll by too fast for me to see them and then that
"old favorite"

Fatal error (11)Segmentation fault

What am I doing wrong???

Bruce

--
+-------------------+--------------------------------------- ------------+
Bruce Bowler | Get someone else to blow your horn and the sound
1.207.633.9600 | will carry twice as far - Will Rogers
bbowler@bigelow.org |
+-------------------+--------------------------------------- ------------+
Re: idlwave segfault [message #69369 is a reply to message #69329] Fri, 15 January 2010 14:26 Go to previous messageGo to next message
JDS is currently offline  JDS
Messages: 94
Registered: March 2009
Member
On Jan 13, 4:23 pm, Bruce Bowler <bbow...@bigelow.org> wrote:
> On Wed, 13 Jan 2010 20:32:28 +0000, Bruce Bowler wrote:
>> On Wed, 13 Jan 2010 09:11:18 -0700, savoie wrote:
>
>>> Bruce Bowler <bbow...@bigelow.org> writes:
>
>>>> On Wed, 13 Jan 2010 07:53:23 -0700, savoie wrote:
>>>> > I'm just taking wild stabs in the dark, but are you starting emacs
>>>> > from the command line?  The same one that your running IDL
>>>> > successfully from?
>
>>>> Wild stabs are fine at this point, it's what I'm doing too... Yes,
>>>> same command line, same environment
>
>>> Can you compare your environmental variables before starting emacs with
>>> those in a shell started in emacs (M-x shell)?  What are the
>>> differences?
>
>>> Matt
>
>> in the shell TERM=xterm while in emacs M-x shell it's dumb.
>
>> In shell LS_COLORS has a litany of things, in emacs it's empty
>
>> in emacs, EMACS=t and INSIDE_EMACS=22.3.1,comint also in emacs, TERMCAP=
>> and COLUMNS=80.  Neither are define in the shell.
>
>> In emacs, path as the last element duplicated (/opt/real/RealPlayer)
>
>> and in shell, shlvl=2 and in emacs it's 3.
>
>> In otherwords, not much is different.
>
> Matt,
>
> Following up on your emailed suggestion (here so everyone knows and maybe
> JD will have an idea)...
>
> If I start emacs, M-x shell and run IDL from that shell, things *DO NOT*
> crash.
>
> Hopefully that's a big clue to someone far smarter than I am.
>
>

I can only suggest running it under gdb (gdb /usr/bin/emacs then "run"
at the prompt), to see if the segfault occurs anywhere interesting.
Crashing IDL should *not* bring down emacs (just as it does not bring
down a normal shell). So could be some problem with your Emacs, and
potentially X11.

JD
Re: idlwave segfault [message #69397 is a reply to message #69329] Wed, 13 January 2010 13:23 Go to previous messageGo to next message
Bruce Bowler is currently offline  Bruce Bowler
Messages: 128
Registered: September 1998
Senior Member
On Wed, 13 Jan 2010 20:32:28 +0000, Bruce Bowler wrote:

> On Wed, 13 Jan 2010 09:11:18 -0700, savoie wrote:
>
>> Bruce Bowler <bbowler@bigelow.org> writes:
>>
>>> On Wed, 13 Jan 2010 07:53:23 -0700, savoie wrote:
>>>> I'm just taking wild stabs in the dark, but are you starting emacs
>>>> from the command line? The same one that your running IDL
>>>> successfully from?
>>
>>> Wild stabs are fine at this point, it's what I'm doing too... Yes,
>>> same command line, same environment
>>
>> Can you compare your environmental variables before starting emacs with
>> those in a shell started in emacs (M-x shell)? What are the
>> differences?
>>
>> Matt
>
> in the shell TERM=xterm while in emacs M-x shell it's dumb.
>
> In shell LS_COLORS has a litany of things, in emacs it's empty
>
> in emacs, EMACS=t and INSIDE_EMACS=22.3.1,comint also in emacs, TERMCAP=
> and COLUMNS=80. Neither are define in the shell.
>
> In emacs, path as the last element duplicated (/opt/real/RealPlayer)
>
> and in shell, shlvl=2 and in emacs it's 3.
>
> In otherwords, not much is different.

Matt,

Following up on your emailed suggestion (here so everyone knows and maybe
JD will have an idea)...

If I start emacs, M-x shell and run IDL from that shell, things *DO NOT*
crash.

Hopefully that's a big clue to someone far smarter than I am.

Bruce

--
+-------------------+--------------------------------------- ------------+
Bruce Bowler | I never met a chocolate I didn't like - Deanna
1.207.633.9600 | Troi
bbowler@bigelow.org |
+-------------------+--------------------------------------- ------------+
Re: idlwave segfault [message #69401 is a reply to message #69329] Wed, 13 January 2010 12:32 Go to previous messageGo to next message
Bruce Bowler is currently offline  Bruce Bowler
Messages: 128
Registered: September 1998
Senior Member
On Wed, 13 Jan 2010 09:11:18 -0700, savoie wrote:

> Bruce Bowler <bbowler@bigelow.org> writes:
>
>> On Wed, 13 Jan 2010 07:53:23 -0700, savoie wrote:
>>> I'm just taking wild stabs in the dark, but are you starting emacs
>>> from the command line? The same one that your running IDL
>>> successfully from?
>
>> Wild stabs are fine at this point, it's what I'm doing too... Yes, same
>> command line, same environment
>
> Can you compare your environmental variables before starting emacs with
> those in a shell started in emacs (M-x shell)? What are the
> differences?
>
> Matt

in the shell TERM=xterm while in emacs M-x shell it's dumb.

In shell LS_COLORS has a litany of things, in emacs it's empty

in emacs, EMACS=t and INSIDE_EMACS=22.3.1,comint
also in emacs, TERMCAP= and COLUMNS=80. Neither are define in the shell.

In emacs, path as the last element duplicated (/opt/real/RealPlayer)

and in shell, shlvl=2 and in emacs it's 3.

In otherwords, not much is different.


--
+-------------------+--------------------------------------- ------------+
Bruce Bowler | Don't ever go to Pluto. It's a Mickey Mouse planet.
1.207.633.9600 | - Robin Williams
bbowler@bigelow.org |
+-------------------+--------------------------------------- ------------+
Re: idlwave segfault [message #69405 is a reply to message #69329] Wed, 13 January 2010 08:11 Go to previous messageGo to next message
Matt[2] is currently offline  Matt[2]
Messages: 69
Registered: March 2007
Member
Bruce Bowler <bbowler@bigelow.org> writes:

> On Wed, 13 Jan 2010 07:53:23 -0700, savoie wrote:
>> I'm just taking wild stabs in the dark, but are you starting emacs from
>> the command line? The same one that your running IDL successfully from?

> Wild stabs are fine at this point, it's what I'm doing too...
> Yes, same command line, same environment

Can you compare your environmental variables before starting emacs with
those in a shell started in emacs (M-x shell)? What are the
differences?

Matt

--
Matthew Savoie - Scientific Programmer
National Snow and Ice Data Center
(303) 735-0785 http://nsidc.org
Re: idlwave segfault [message #69406 is a reply to message #69329] Wed, 13 January 2010 06:59 Go to previous messageGo to next message
Bruce Bowler is currently offline  Bruce Bowler
Messages: 128
Registered: September 1998
Senior Member
On Wed, 13 Jan 2010 07:53:23 -0700, savoie wrote:

> Bruce Bowler <bbowler@bigelow.org> writes:
>
>> JD comes closest with the above comment about DISPLAY. If I set my
>> display to a nonsensical value (:1.1) and fire up emacs and hit C-c
>> C-s, the shell starts and works properly. Better than nothing but VERY
>> far from ideal... Now to figure out what's "broken" with X (ughhhh)
>
> I'm just taking wild stabs in the dark, but are you starting emacs from
> the command line? The same one that your running IDL successfully from?
>
> M

Wild stabs are fine at this point, it's what I'm doing too...


Yes, same command line, same environment

--
+-------------------+--------------------------------------- ------------+
Bruce Bowler | I'm as confused as a new-born in a topless bar...
1.207.633.9600 | - Anonymous
bbowler@bigelow.org |
+-------------------+--------------------------------------- ------------+
Re: idlwave segfault [message #69407 is a reply to message #69329] Wed, 13 January 2010 06:53 Go to previous messageGo to next message
Matt[2] is currently offline  Matt[2]
Messages: 69
Registered: March 2007
Member
Bruce Bowler <bbowler@bigelow.org> writes:

> JD comes closest with the above comment about DISPLAY. If I set my
> display to a nonsensical value (:1.1) and fire up emacs and hit C-c C-s,
> the shell starts and works properly. Better than nothing but VERY far
> from ideal... Now to figure out what's "broken" with X (ughhhh)

I'm just taking wild stabs in the dark, but are you starting emacs from
the command line? The same one that your running IDL successfully from?

M

--
Matthew Savoie - Scientific Programmer
National Snow and Ice Data Center
(303) 735-0785 http://nsidc.org
Re: idlwave segfault [message #69411 is a reply to message #69329] Tue, 12 January 2010 13:41 Go to previous messageGo to next message
Bruce Bowler is currently offline  Bruce Bowler
Messages: 128
Registered: September 1998
Senior Member
On Tue, 12 Jan 2010 11:34:53 -0800, JD Smith wrote:
>
> I've seen segfaults in IDL based on incorrectly
> set DISPLAY parameters, and other things.
>
> JD


First, thanks to all for their advice so far...

JD comes closest with the above comment about DISPLAY. If I set my
display to a nonsensical value (:1.1) and fire up emacs and hit C-c C-s,
the shell starts and works properly. Better than nothing but VERY far
from ideal... Now to figure out what's "broken" with X (ughhhh)

Bruce

--
+-------------------+--------------------------------------- ------------+
Bruce Bowler | I'd rather wake up in the middle of nowhere than in
1.207.633.9600 | any city on earth. - Steve McQueen
bbowler@bigelow.org |
+-------------------+--------------------------------------- ------------+
Re: idlwave segfault [message #69412 is a reply to message #69329] Tue, 12 January 2010 12:42 Go to previous messageGo to next message
Bruce Bowler is currently offline  Bruce Bowler
Messages: 128
Registered: September 1998
Senior Member
On Tue, 12 Jan 2010 11:55:48 -0800, pp wrote:

> On Jan 12, 5:34 pm, JD Smith <jdtsmith.nos...@yahoo.com> wrote:
>> There are various reasons why this test isn't conclusive.  One of the
>> main problems has to do with the environment present in the Emacs
>> session vs. your shell.  I've seen segfaults in IDL based on
>> incorrectly set DISPLAY parameters, and other things.  Launch emacs
>> from the shell with emacs -q to skip your .emacs init file, and see if
>> that changes anything.
>
> In that case, I would check the most common cause I have seen for
> segfaults when starting recent versions of IDL. It is the use of the
> OpenGL drivers supplied with it, in the files gl_* in the idl71/bin/
> bin.linux.x86 and idl71/bin/bin.linux.x86_64 directories. Moving those
> files somewhere they will not be found by IDL fixes that issue.

mv'ed them to a completely mangled filename. No change.




--
+-------------------+--------------------------------------- ------------+
Bruce Bowler | I don't have to look up my family tree, because I
1.207.633.9600 | know that I'm the sap - Fred Allen
bbowler@bigelow.org |
+-------------------+--------------------------------------- ------------+
Re: idlwave segfault [message #69413 is a reply to message #69329] Tue, 12 January 2010 12:36 Go to previous messageGo to next message
Bruce Bowler is currently offline  Bruce Bowler
Messages: 128
Registered: September 1998
Senior Member
On Tue, 12 Jan 2010 11:22:10 -0700, savoie wrote:

> Bruce Bowler <bbowler@bigelow.org> writes:
>
>> You are correct, I didn't explicitly state that I tried that.
>>
>> I did try (and succeed) in launching and using IDL from a shell prompt
>> so it appears to me that it's strictly an idlwave problem, not a more
>> generic IDL issue.
>
> Bruce,
>
> Can you see if you have an old version of idlwave installed? M-x
> list-load-path-shadows
>
> When it crashes, what's left in the *messages* buffer, any clues there?
>
> Matt

M-x list-load-path-shadows puts the message "No Emacs Lisp load-path
shadowings were found"

When "it" crashes "it" takes emacs along with it, so there's no way (that
I know of) to look at the *messages* buffer.

--
+-------------------+--------------------------------------- ------------+
Bruce Bowler | I wouldn't live in California. All that sun makes
1.207.633.9600 | you sterile. - Alan Alda
bbowler@bigelow.org |
+-------------------+--------------------------------------- ------------+
Re: idlwave segfault [message #69414 is a reply to message #69329] Tue, 12 January 2010 12:31 Go to previous messageGo to next message
Bruce Bowler is currently offline  Bruce Bowler
Messages: 128
Registered: September 1998
Senior Member
On Tue, 12 Jan 2010 11:34:53 -0800, JD Smith wrote:
> There are various reasons why this test isn't conclusive. One of the
> main problems has to do with the environment present in the Emacs
> session vs. your shell. I've seen segfaults in IDL based on incorrectly
> set DISPLAY parameters, and other things. Launch emacs from the shell
> with emacs -q to skip your .emacs init file, and see if that changes
> anything.

emacs -q still segfaults when I try and do anything in the IDL buffer in
emacs.

echo $DISPLAY results in :0.0 which is, as far as I know (I'm far from a
wizard) correct

IDL, by itself, does what I ask of it, graphics-wise, X-wise, etc





--
+-------------------+--------------------------------------- ------------+
Bruce Bowler | Don't take life too seriously, it's not permanent -
1.207.633.9600 | Anon
bbowler@bigelow.org |
+-------------------+--------------------------------------- ------------+
Re: idlwave segfault [message #69415 is a reply to message #69329] Tue, 12 January 2010 11:55 Go to previous messageGo to next message
penteado is currently offline  penteado
Messages: 866
Registered: February 2018
Senior Member
Administrator
On Jan 12, 5:34 pm, JD Smith <jdtsmith.nos...@yahoo.com> wrote:
> There are various reasons why this test isn't conclusive.  One of the
> main problems has to do with the environment present in the Emacs
> session vs. your shell.  I've seen segfaults in IDL based on
> incorrectly set DISPLAY parameters, and other things.  Launch emacs
> from the shell with emacs -q to skip your .emacs init file, and see if
> that changes anything.

In that case, I would check the most common cause I have seen for
segfaults when starting recent versions of IDL. It is the use of the
OpenGL drivers supplied with it, in the files gl_* in the idl71/bin/
bin.linux.x86 and idl71/bin/bin.linux.x86_64 directories. Moving
those files somewhere they will not be found by IDL fixes that issue.
Re: idlwave segfault [message #69463 is a reply to message #69329] Thu, 07 January 2010 05:52 Go to previous messageGo to next message
Bruce Bowler is currently offline  Bruce Bowler
Messages: 128
Registered: September 1998
Senior Member
On Tue, 05 Jan 2010 19:06:43 +0000, Bruce Bowler wrote:

> I'm pretty sure I've seen this mentioned before but google isn't helping
> me find it if I'm correct...
>
> I'm running Fedora 10, Emacs 22.3.1 and idlwave 6.1_em22 (all "defaults"
> for F10, as far as I know).
>
> When I try to start an IDL shell from within emacs (via C-c C-s), I get
> a few messages that scroll by too fast for me to see them and then that
> "old favorite"
>
> Fatal error (11)Segmentation fault
>
> What am I doing wrong???
>
> Bruce

More info in the event that it helps.

If I start the shell with C-c C-l the shell successfully starts, but as
soon as I enter the *idl* buffer, I get the segfault.

I can't say for sure when this started since it's been a while since I've
done much/any IDL editing...

Thanks for any help and/or suggestions you might have to offer.

--
+-------------------+--------------------------------------- ------------+
Bruce Bowler | I do some of my best work in the basement. - Ross
1.207.633.9600 | Donolow
bbowler@bigelow.org |
+-------------------+--------------------------------------- ------------+
Re: idlwave segfault [message #69488 is a reply to message #69329] Tue, 19 January 2010 09:52 Go to previous messageGo to next message
Foldy Lajos is currently offline  Foldy Lajos
Messages: 268
Registered: October 2001
Senior Member
On Tue, 19 Jan 2010, Bruce Bowler wrote:

> I guess, for the time begin, since I'm completely out of ideas, not to
> mention lost, I'm stuck without the full benefit of idlwave...

You can try 'strace' to trace system calls and signals before the crash:

strace -f -o output.strace /usr/bin/emacs-x11 myprog.pro

regards,
Lajos
Re: idlwave segfault [message #69491 is a reply to message #69369] Tue, 19 January 2010 08:17 Go to previous messageGo to next message
Bruce Bowler is currently offline  Bruce Bowler
Messages: 128
Registered: September 1998
Senior Member
On Fri, 15 Jan 2010 14:26:09 -0800, JD Smith wrote:

> On Jan 13, 4:23 pm, Bruce Bowler <bbow...@bigelow.org> wrote:
>> On Wed, 13 Jan 2010 20:32:28 +0000, Bruce Bowler wrote:
>>> On Wed, 13 Jan 2010 09:11:18 -0700, savoie wrote:
>>
>>>> Bruce Bowler <bbow...@bigelow.org> writes:
>>
>>>> > On Wed, 13 Jan 2010 07:53:23 -0700, savoie wrote:
>>>> >> I'm just taking wild stabs in the dark, but are you starting emacs
>>>> >> from the command line?  The same one that your running IDL
>>>> >> successfully from?
>>
>>>> > Wild stabs are fine at this point, it's what I'm doing too... Yes,
>>>> > same command line, same environment
>>
>>>> Can you compare your environmental variables before starting emacs
>>>> with those in a shell started in emacs (M-x shell)?  What are the
>>>> differences?
>>
>>>> Matt
>>
>>> in the shell TERM=xterm while in emacs M-x shell it's dumb.
>>
>>> In shell LS_COLORS has a litany of things, in emacs it's empty
>>
>>> in emacs, EMACS=t and INSIDE_EMACS=22.3.1,comint also in emacs,
>>> TERMCAP= and COLUMNS=80.  Neither are define in the shell.
>>
>>> In emacs, path as the last element duplicated (/opt/real/RealPlayer)
>>
>>> and in shell, shlvl=2 and in emacs it's 3.
>>
>>> In otherwords, not much is different.
>>
>> Matt,
>>
>> Following up on your emailed suggestion (here so everyone knows and
>> maybe JD will have an idea)...
>>
>> If I start emacs, M-x shell and run IDL from that shell, things *DO
>> NOT* crash.
>>
>> Hopefully that's a big clue to someone far smarter than I am.
>>
>>
>>
> I can only suggest running it under gdb (gdb /usr/bin/emacs then "run"
> at the prompt), to see if the segfault occurs anywhere interesting.
> Crashing IDL should *not* bring down emacs (just as it does not bring
> down a normal shell). So could be some problem with your Emacs, and
> potentially X11.
>
> JD

Ugghhhhh... gdb -args emacs testbcb.pro hangs when I do the C-c C-s
thing, despite adding about 50 -debuginfo packages it was complaining
weren't found (it works fine before that key sequence). The last thing
emacs spits out (on the status line) is "Loading idlw-shell...done"

I guess, for the time begin, since I'm completely out of ideas, not to
mention lost, I'm stuck without the full benefit of idlwave...

Bruce

--
+-------------------+--------------------------------------- ------------+
Bruce Bowler | When you're dodging bullets, it's hard to do long
1.207.633.9600 | term planning. - Charlie Plum
bbowler@bigelow.org |
+-------------------+--------------------------------------- ------------+
Re: idlwave segfault [message #69525 is a reply to message #69488] Mon, 25 January 2010 06:56 Go to previous message
Bruce Bowler is currently offline  Bruce Bowler
Messages: 128
Registered: September 1998
Senior Member
On Tue, 19 Jan 2010 18:52:11 +0100, FÖLDY Lajos wrote:

> On Tue, 19 Jan 2010, Bruce Bowler wrote:
>
>> I guess, for the time begin, since I'm completely out of ideas, not to
>> mention lost, I'm stuck without the full benefit of idlwave...
>
> You can try 'strace' to trace system calls and signals before the crash:
>
> strace -f -o output.strace /usr/bin/emacs-x11 myprog.pro
>
> regards,
> Lajos


Well, after a weeks break, I'm back at this problem. I did that and now
have a 750K output file. Most of that is, I'm sure, meaningless, but
there's certainly useful information but I'm "relatively ignorant" of how
to read it. Are there tools to help distill the info? Anyone care to
take a look at the last 50-100 lines?

(here's the last 120 or so lines, in case you do, with some snippage
after the sigsegv. oh and watch out for line wrapping)

Thanks!
Bruce

5409 read(4, "\26:\331\23I\1\240\3I\1\240\3\0\0\0\0\2\0\0\0\20\0\352\0\0
\0\0\277I\1\240\3"..., 4096) = 96
5409 read(4, 0x85d47d4, 4096) = -1 EAGAIN (Resource temporarily
unavailable)
5409 poll([{fd=4, events=POLLIN}], 1, 0) = 0 (Timeout)
5409 poll([{fd=4, events=POLLIN}], 1, 0) = 0 (Timeout)
5409 select(5, [4], [4], NULL, NULL) = 1 (out [4])
5409 writev(4, [{"=\0\4\0t\0\240\3\2\0\352\0\20\0\4\1", 16}], 1) = 16
5409 read(4, 0x85d47d4, 4096) = -1 EAGAIN (Resource temporarily
unavailable)
5409 read(4, 0x85d47d4, 4096) = -1 EAGAIN (Resource temporarily
unavailable)
5409 poll([{fd=4, events=POLLIN}], 1, 0) = 0 (Timeout)
5409 select(6, [5], NULL, NULL, {0, 0}) = 0 (Timeout)
5409 read(4, 0x85d47d4, 4096) = -1 EAGAIN (Resource temporarily
unavailable)
5409 --- SIGALRM (Alarm clock) @ 0 (0) ---
5409 gettimeofday({1264427927, 265461}, NULL) = 0
5409 sigreturn() = ? (mask now [])
5409 poll([{fd=4, events=POLLIN}], 1, 0) = 0 (Timeout)
5636 getgid32() = 100
5636 access("/bin/arch", X_OK) = 0
5636 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
5636 pipe([3, 4]) = 0
5636 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
5636 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
5636 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) = 0
5636 _llseek(255, -1682, [9700], SEEK_CUR) = 0
5636 clone( <unfinished ...>
5409 select(5, [4], [4], NULL, NULL) = 1 (out [4])
5409 writev(4, [{"\\\0\5\0 \0\0\0\6\0\352\0grey75\0\0", 20}], 1) = 20
5409 --- SIGIO (I/O possible) @ 0 (0) ---
5409 sigreturn() = ? (mask now [])
5409 select(5, [4], [], NULL, NULL) = 1 (in [4])
5409 read(4, "\1i8\24\0\0\0\0\277\277\277\277\277\277\277\277\277\277\277
\277\24\0\0\0X\4\0\0008\7\234\10", 4096) = 32
5636 <... clone resumed> child_stack=0, flags=CLONE_CHILD_CLEARTID|
CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7fe7708) = 5645
5645 close(255) = 0
5645 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
5645 rt_sigaction(SIGTSTP, {SIG_DFL, [], 0}, {SIG_DFL, [], 0}, 8) = 0
5645 rt_sigaction(SIGTTIN, {SIG_DFL, [], 0}, {SIG_DFL, [], 0}, 8) = 0
5645 rt_sigaction(SIGTTOU, {SIG_DFL, [], 0}, {SIG_DFL, [], 0}, 8) = 0
5645 rt_sigaction(SIGINT, {SIG_DFL, [], 0}, {SIG_DFL, [], 0}, 8) = 0
5645 rt_sigaction(SIGQUIT, {SIG_DFL, [], 0}, {SIG_IGN, [], 0}, 8) = 0
5645 rt_sigaction(SIGCHLD, {SIG_DFL, [], 0}, {0x807bad0, [], 0}, 8) = 0
5645 rt_sigaction(SIGCHLD, {0x807bad0, [], 0}, {SIG_DFL, [], 0}, 8) = 0
5645 rt_sigaction(SIGINT, {0x808f660, [], 0}, {SIG_DFL, [], 0}, 8) = 0
5645 dup2(4, 1) = 1
5645 close(4) = 0
5645 close(3) = 0
5645 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
5645 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
5645 rt_sigaction(SIGINT, {SIG_DFL, [], 0}, {0x808f660, [], 0}, 8) = 0
5645 rt_sigaction(SIGQUIT, {SIG_DFL, [], 0}, {SIG_DFL, [], 0}, 8) = 0
5645 rt_sigaction(SIGCHLD, {SIG_DFL, [], 0}, {0x807bad0, [], 0}, 8) = 0
5645 execve("/bin/arch", ["/bin/arch"], [/* 129 vars */] <unfinished ...>
5636 rt_sigprocmask(SIG_SETMASK, [], <unfinished ...>
5409 read(4, <unfinished ...>
5636 <... rt_sigprocmask resumed> NULL, 8) = 0
5409 <... read resumed> 0x85d47d4, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
5636 rt_sigaction(SIGCHLD, {0x807bad0, [], 0}, <unfinished ...>
5409 select(5, [4], [4], NULL, NULL <unfinished ...>
5636 <... rt_sigaction resumed> {0x807bad0, [], 0}, 8) = 0
5409 <... select resumed> ) = 1 (out [4])
5636 close(4 <unfinished ...>
5409 writev(4, [{"T\0\4\0 \0\0\0\277\277\277\277\277\277ey", 16}], 1
<unfinished ...>
5636 <... close resumed> ) = 0
5409 <... writev resumed> ) = 16
5636 read(3, <unfinished ...>
5409 --- SIGIO (I/O possible) @ 0 (0) ---
5409 sigreturn() = ? (mask now [])
5409 select(5, [4], [], NULL, NULL) = 1 (in [4])
5409 read(4, "\1i9\24\0\0\0\0\277\277\277\277\277\277\234\10\277\277\277
\0\20\0\0\0X\4\0\0008\7\234\10", 4096) = 32
5409 read(4, 0x85d47d4, 4096) = -1 EAGAIN (Resource temporarily
unavailable)
5409 select(6, [5], NULL, NULL, {0, 0}) = 0 (Timeout)
5409 read(4, 0x85d47d4, 4096) = -1 EAGAIN (Resource temporarily
unavailable)
5409 poll([{fd=4, events=POLLIN}], 1, 0) = 0 (Timeout)
5409 select(5, [4], [4], NULL, NULL <unfinished ...>
5645 <... execve resumed> ) = 0
5409 <... select resumed> ) = 1 (out [4])
5409 writev(4, [{"\\\0\5\0 \0\0\0\5\0\277\277black5\0\0", 20}], 1) = 20
5409 --- SIGIO (I/O possible) @ 0 (0) ---
5409 sigreturn() = ? (mask now [])
5409 select(5, [4], [], NULL, NULL <unfinished ...>
5645 brk(0 <unfinished ...>
5409 <... select resumed> ) = 1 (in [4])
5645 <... brk resumed> ) = 0x8051000
5409 read(4, <unfinished ...>
5645 access("/etc/ld.so.preload", R_OK <unfinished ...>
5409 <... read resumed> "\1i:\24\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\24\0\0
\0X\4\0\0008\7\234\10", 4096) = 32
5645 <... access resumed> ) = -1 ENOENT (No such file or
directory)
5409 read(4, <unfinished ...>
5645 open("/etc/ld.so.cache", O_RDONLY <unfinished ...>
5409 <... read resumed> 0x85d47d4, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
5645 <... open resumed> ) = 3
5409 select(5, [4], [4], NULL, NULL <unfinished ...>
5645 fstat64(3, <unfinished ...>
5409 <... select resumed> ) = 1 (out [4])
5645 <... fstat64 resumed> {st_mode=S_IFREG|0644, st_size=92727, ...}) =
0
5409 writev(4, [{"T\0\4\0 \0\0\0\0\0\0\0\0\0ac", 16}], 1 <unfinished ...>
5645 mmap2(NULL, 92727, PROT_READ, MAP_PRIVATE, 3, 0 <unfinished ...>
5409 <... writev resumed> ) = 16
5645 <... mmap2 resumed> ) = 0xb7fe9000
5409 --- SIGIO (I/O possible) @ 0 (0) ---
5645 close(3 <unfinished ...>
5409 sigreturn( <unfinished ...>
5645 <... close resumed> ) = 0
5409 <... sigreturn resumed> ) = ? (mask now [])
5645 open("/lib/libc.so.6", O_RDONLY <unfinished ...>
5409 select(5, [4], [], NULL, NULL <unfinished ...>
5645 <... open resumed> ) = 3
5409 <... select resumed> ) = 1 (in [4])
5645 read(3, <unfinished ...>
5409 read(4, <unfinished ...>
5645 <... read resumed> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0
\0@h\1\0004\0\0\0"..., 512) = 512
5409 <... read resumed> "\1i;\24\0\0\0\0\0\0\0\0\0\0\234\10\0\0\0\0\20\0
\0\0X\4\0\0008\7\234\10", 4096) = 32
5645 fstat64(3, <unfinished ...>
5409 read(4, <unfinished ...>
5645 <... fstat64 resumed> {st_mode=S_IFREG|0755, st_size=1806256, ...})
= 0
5409 <... read resumed> 0x85d47d4, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
5409 select(6, [5], NULL, NULL, {0, 0}) = 0 (Timeout)
5409 read(4, 0x85d47d4, 4096) = -1 EAGAIN (Resource temporarily
unavailable)
5409 poll([{fd=4, events=POLLIN}], 1, 0) = 0 (Timeout)
5409 brk(0x891b000) = 0x891b000
5409 --- SIGSEGV (Segmentation fault) @ 0 (0) ---



--
+-------------------+--------------------------------------- ------------+
Bruce Bowler | Never eat more than you can lift. - Miss Piggy
1.207.633.9600 |
bbowler@bigelow.org |
+-------------------+--------------------------------------- ------------+
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: oplot
Next Topic: Mode and variation of cells in multiple grids (3-D problem)

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Oct 08 13:45:53 PDT 2025

Total time taken to generate the page: 0.00452 seconds