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

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

while poking around with this problem, i ran dbx again, this time
without the core file and executing it with 'run 1.pdf'
after it core dumps, the 'where' command yields different results than
those from my first post:

Reading pdftk
Reading ld.so.1
Reading libgcjgc.so.1.0.1
Reading libpthread.so.1
Reading librt.so.1
Reading libnsl.so.1
Reading libdl.so.1
Reading libsocket.so.1
Reading libiconv.so.2.4.0
Reading libm.so.2
Reading libgcc_s.so.1
Reading libc.so.1
Reading libaio.so.1
Reading libmd5.so.1
detected a multithreaded program
(/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
  [6] _Z10_Jv_InitGCv(0x0, 0x1, 0xa1964, 0x0, 0x7e5664, 0xfef6b3d4), at
0x3d7e44
  [7] _Z16_Jv_CreateJavaVMPv(0xffffffff, 0x4cf5a0, 0xff730702,
0xfffffffe, 0x80808080, 0x1010101), at 0x3028a0
  [8] main(0x2, 0xffbffbc4, 0x0, 0x0, 0xff310100, 0xff310140), at
0x1c823c
(/opt/SUNWspro/bin/../WS5.0/bin/sparcv9/dbx) quit

is this actually a garbage collection issue?  i found GC_find_limit in
the boehm-gc directory.

thanks in advance for any help...
lloyd knight