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

[Andrew Haley <aph-gcc at littlepinkcloud dot COM>]

Knight, Lloyd writes:
 > hans,
 > thanks for the reply.
 > 
 > sorry, but i'm missing the point of your reply.
 > is there anything i can try?

Continue after the SEGV.

 > 
 > note this is the same application combination you helped
 > me with on solaris 8 a week ago. (including -lpthread in the link
 > statement)
 > 
 > sorry for being so thick headed...
 > thanks for you help.
 > 
 > lloyd knight

All this top-posting is driving me crazy.

 > -----Original Message-----
 > From: Hans Boehm [mailto:Hans.Boehm@hp.com] 
 > Sent: Friday, April 20, 2007 11:22 AM
 > To: David Daney
 > Cc: Knight, Lloyd; java@gcc.gnu.org
 > Subject: Re: pdftk1.4.1, gcc3.4.6 on solaris 10 core dumps.
 > 
 > Note that the purpose of GC_find_limit is to find the bounds of an
 > address mapping by touching memory until it faults, and then catching
 > the SIGSEGV.
 > The SIGSEGV here is probably expected and normal.  If it is not caught
 > that's a problem.  Seeing it in idb or dbx is not.
 > 
 > Hans
 > 
 > On Fri, 20 Apr 2007, David Daney wrote:
 > 
 > > Knight, Lloyd wrote:
 > >
 > > > (/opt/SUNWspro/bin/../WS5.0/bin/sparcv9/dbx) run ./1.pdf
 > > > Running: pdftk ./1.pdf
 > > > (process id 25708)
 > > > Reading libc_psr.so.1
 > > > (l@1) signal SEGV (no mapping at the fault address) in GC_find_limit
 > 
 > > > at
 > > > 0x3e3688
 > > > 0x003e3688: GC_find_limit+0x0070:       ldsb    [%g1], %o0
 > > > (/opt/SUNWspro/bin/../WS5.0/bin/sparcv9/dbx) where =>[1] 
 > > > GC_find_limit(0xffbff7fc, 0x7d8698, 0xffffffff, 0xfffffff8, 0x0, 
 > > > 0x7f0000), at 0x3e3688
 > > >   [2] GC_get_stack_base(0x7cbf20, 0x7cc060, 0xa1964, 0xfeec6964, 
 > > > 0x0, 0x0), at 0x3e36f4
 > > >   [3] GC_init_inner(0x0, 0x1084, 0x0, 0x0, 0x0, 0x0), at 0x3e2ad0
 > > >   [4] GC_init(0x7d9010, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x3e2cdc
 > > >   [5] GC_init_gcj_malloc(0x0, 0x3d6f08, 0x0, 0x0, 0x0, 0x0), at 
 > > > 0x3dc564
 > >
 > > Recently on this list there have been other reports of problems in the
 > 
 > > GC on Solaris.  Not that it helps much, but I think you are not the 
 > > only one effected by whatever the problem is.  Try searching the list 
 > > archives to see if you find helpful suggestions.
 > >
 > >
 > > Perhaps I should pull my IPX out of the garage and see if I can build 
 > > gcj on it.  I don't think it would be fun, as it is much slower and 
 > > has less memory than my MIPS boards that take about a week to 
 > > bootstrap and test the compiler...
 > >
 > > David Daney
 > >