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.
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
> >