This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: pdftk1.4.1, gcc3.4.6 on solaris 10 core dumps.
- From: "Knight, Lloyd" <Lloyd dot Knight at adc dot com>
- To: "Hans Boehm" <Hans dot Boehm at hp dot com>, "David Daney" <ddaney at avtrex dot com>
- Cc: <java at gcc dot gnu dot org>
- Date: Fri, 20 Apr 2007 11:36:32 -0500
- Subject: RE: pdftk1.4.1, gcc3.4.6 on solaris 10 core dumps.
hans,
thanks for the reply.
sorry, but i'm missing the point of your reply.
is there anything i can try?
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
-----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
>