|
From: strk <st...@ke...> - 2005-03-15 18:03:22
|
On Tue, Mar 15, 2005 at 11:56:01AM -0600, Nicholas Nethercote wrote: > On Tue, 15 Mar 2005, strk wrote: > > >==26276== Conditional jump or move depends on uninitialised value(s) > >==26276== at 0x1C057E52: GC_push_all_eager (mark.c:1469) > >==26276== by 0x1C0593EE: GC_push_current_stack (mark_rts.c:488) > >==26276== by 0x1C060714: GC_generic_push_regs (mach_dep.c:452) > >==26276== by 0x1C059555: GC_push_roots (mark_rts.c:628) > >==26276== by 0x1C05898E: GC_mark_some (mark.c:326) > >==26276== by 0x1C04FCCA: GC_stopped_mark (alloc.c:517) > >==26276== by 0x1C050683: GC_try_to_collect_inner (alloc.c:364) > >==26276== by 0x1C05A4B9: GC_init_inner (misc.c:758) > >==26276== by 0x1C05A6DD: GC_init (misc.c:477) > >==26276== by 0x1C054448: GC_init_gcj_malloc (gcj_mlc.c:60) > >==26276== by 0x1BE5D5C6: _Jv_InitGC() (boehm.cc:526) > >==26276== by 0x1BE5FAAE: _Jv_CreateJavaVM(void*) (prims.cc:907) > > I'm guessing the GC violates Memcheck's assumptions about the use of > uninitialised memory... garbage collectors often manipulate memory in > low-level ways (eg. poke a page and see if it seg faults, and catch the > signal if so). > > I would guess that GCJ would need to be augmented with client requests > that pass the necessary info to Memcheck to avoid these warnings. That > could be difficult. > > However, if you just want leak checking, try --tool=addrcheck, which > doesn't do the undefinedness checks. $ valgrind --tool=addrcheck ./jtstest data1 > /dev/null ... ==26360== Invalid read of size 4 ==26360== at 0x3489DE40: GC_push_all_eager (mark.c:1468) ==26360== by 0x3489DEB1: GC_push_all_stack (mark.c:1521) ==26360== by 0x348A6197: GC_push_all_stacks (pthread_stop_world.c:232) ==26360== by 0x348A14D6: GC_default_push_other_roots (os_dep.c:1990) ==26360== by 0x3489F563: GC_push_roots (mark_rts.c:643) ==26360== by 0x3489E98E: GC_mark_some (mark.c:326) ==26360== by 0x34895CCA: GC_stopped_mark (alloc.c:517) ==26360== by 0x34896683: GC_try_to_collect_inner (alloc.c:364) ==26360== by 0x34896EAD: GC_collect_or_expand (alloc.c:1007) ==26360== by 0x34897069: GC_allocobj (alloc.c:1058) ==26360== by 0x3489B68E: GC_generic_malloc_inner (malloc.c:134) ==26360== by 0x3489C42E: GC_generic_malloc_many (mallocx.c:500) ==26360== Address 0x9BDFF8CC is on thread 3's stack ... [ then hangs here ] |