RE: pdftk1.4.1, gcc3.4.6 on solaris 10 core dumps.

["Knight, Lloyd" <Lloyd dot Knight at adc dot com>]

actually, no.
i tried "ignore SIGSEGV" in dbx and it behaved
the same.  it may be a defect in this dbx version. 

i am more curious as to what setting the LC_* variables
has to do with allowing the gc to behave as expected, thus
allowing pdftk to complete.

thanks
lloyd knight

-----Original Message-----
From: Boehm, Hans [mailto:hans.boehm@hp.com] 
Sent: Monday, April 23, 2007 2:52 PM
To: Knight, Lloyd; Andrew Haley; tromey@redhat.com
Cc: java@gcc.gnu.org
Subject: RE: pdftk1.4.1, gcc3.4.6 on solaris 10 core dumps.

> -----Original Message-----
> From: Knight, Lloyd [mailto:Lloyd.Knight@adc.com]
...
> i do not understand why i have a different stack trace when i run dbx 
> with and without the core file.  and i do not understand why what i 
> did made the segv go away.
> if anyone has an idea as to why this works, i would be interested in 
> hearing....
> 
The SIGSEGV is presumably still being generated.  But it is handled by
the GC, as it should be.  The GC explicitly installs a handler for it,
and removes it once it has determined the stack bounds.  The SIGSEGV
should not cause the process to die.  And all of this is normally
transparent unless a debugger is involved.

I suspect that dbx (or at least your version) doesn't like to continue
past a SIGSEGV, and basically ignores the request to continue.  Telling
it to ignore the signal ("ignore SIGSEGV") instead would probably still
work.  I expect this is purely a debugger misfeature.

Hans