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

[Hans Boehm]

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
>