|
From: strk <st...@ke...> - 2005-03-15 17:23:47
|
Did anyone have success - or are there plans - using valgrind against code linked against libgcj (java compiled by gcc) ? --strk; |
|
From: Jeremy F. <je...@go...> - 2005-03-15 17:35:27
|
strk wrote:
>Did anyone have success - or are there plans - using valgrind
>against code linked against libgcj (java compiled by gcc) ?
>
I would assume that it would just work, though there may be some issues
with how symbols are reported (I don't know how gcj mangles symbols, and
whether Valgrind can demangle them). Have you tried and it didn't work?
J
|
|
From: strk <st...@ke...> - 2005-03-15 17:41:20
|
On Tue, Mar 15, 2005 at 09:35:24AM -0800, Jeremy Fitzhardinge wrote: > strk wrote: > > >Did anyone have success - or are there plans - using valgrind > >against code linked against libgcj (java compiled by gcc) ? > > > I would assume that it would just work, though there may be some issues > with how symbols are reported (I don't know how gcj mangles symbols, and > whether Valgrind can demangle them). Have you tried and it didn't work? > > J Yes. valgrind-2.4.0.rc4. ==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) ==26276== ==26276== Conditional jump or move depends on uninitialised value(s) ==26276== at 0x1C057E52: GC_push_all_eager (mark.c:1469) ==26276== by 0x1C057EB1: GC_push_all_stack (mark.c:1521) ==26276== by 0x1C060197: GC_push_all_stacks (pthread_stop_world.c:232) ==26276== by 0x1C05B4D6: GC_default_push_other_roots (os_dep.c:1990) ==26276== by 0x1C059563: GC_push_roots (mark_rts.c:643) ==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== ==26276== More than 30000 total errors detected. I'm not reporting any more. ==26276== Final error counts will be inaccurate. Go fix your program! ==26276== Rerun with --error-limit=no to disable this cutoff. Note ==26276== that errors may occur in your program without prior warning from ==26276== Valgrind, because errors are no longer being displayed. Note that the code works fine, I just wanted to inspect eventual memory leaks. --strk; |
|
From: Nicholas N. <nj...@cs...> - 2005-03-15 17:56:11
|
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. N |
|
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 ] |
|
From: Nicholas N. <nj...@cs...> - 2005-03-15 19:40:18
|
On Tue, 15 Mar 2005, strk wrote: > $ 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 This might also be caused by the GC doing low-level things that Addrcheck doesn't expect. > ... > [ then hangs here ] That's not so good. Does it hang with --tool=none? If so, can you please file a bug report? Thanks. N |
|
From: strk <st...@ke...> - 2005-03-15 20:22:57
|
On Tue, Mar 15, 2005 at 01:40:10PM -0600, Nicholas Nethercote wrote: > On Tue, 15 Mar 2005, strk wrote: > > >$ 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 > > This might also be caused by the GC doing low-level things that Addrcheck > doesn't expect. > > >... > >[ then hangs here ] > > That's not so good. Does it hang with --tool=none? If so, can you please > file a bug report? Thanks. I take it back. It only took a long time, but returns.. --strk; > > N |
|
From: Jeremy F. <je...@go...> - 2005-03-15 19:54:41
|
strk wrote:
>Yes. valgrind-2.4.0.rc4.
>
>==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)
>
Yeah, that's the Boehm garbage collector. It does stuff which no
correct program should do, like wander around reading random pieces of
memory. I once looked at what it would take to make it valgrind-clean,
and it would be a bit fiddley; you'd need to put in client requests to
tell Valgrind "no, this is actually OK" by twiddling the memory state,
doing the read, then restoring it. I guess a cleaner approach would be
something like VALGRIND_SAFE_MEMREAD/WRITE which says that you really
mean to read/write the address, and you want no complaints...
On the other hand, since the program is using GC, the leak checker
probably won't be able to tell you much. Or are you interested in
Valgrinding some non-Java code linked in with the Java?
You could just use a blanket suppression on CG_* symbols to make all the
noise go away...
J
|
|
From: strk <st...@ke...> - 2005-03-15 20:39:19
|
On Tue, Mar 15, 2005 at 11:54:29AM -0800, Jeremy Fitzhardinge wrote: ... > On the other hand, since the program is using GC, the leak checker > probably won't be able to tell you much. Or are you interested in > Valgrinding some non-Java code linked in with the Java? I'm interested on checking if the non-Java code is leaking... It seems I can't do anything but trust the GC to be working > You could just use a blanket suppression on CG_* symbols to make all the > noise go away... Will the error count NOT increment in that case ? (it gives up after 3000 errors are encountered) --strk; |
|
From: Nicholas N. <nj...@cs...> - 2005-03-16 02:40:18
|
On Tue, 15 Mar 2005, strk wrote: >> You could just use a blanket suppression on CG_* symbols to make all the >> noise go away... > > Will the error count NOT increment in that case ? > (it gives up after 3000 errors are encountered) I think suppressed errors do not count towards the 30000 limit. N> |
|
From: Jeremy F. <je...@go...> - 2005-03-16 02:51:33
|
Nicholas Nethercote wrote:
> On Tue, 15 Mar 2005, strk wrote:
>
>>> You could just use a blanket suppression on CG_* symbols to make all
>>> the
>>> noise go away...
>>
>>
>> Will the error count NOT increment in that case ?
>> (it gives up after 3000 errors are encountered)
>
>
> I think suppressed errors do not count towards the 30000 limit.
And you can use --error-limit=no, of course.
J
|
|
From: Bryan O'S. <bo...@se...> - 2005-03-15 18:05:20
|
On Tue, 2005-03-15 at 09:35 -0800, Jeremy Fitzhardinge wrote: > I would assume that it would just work, though there may be some issues > with how symbols are reported (I don't know how gcj mangles symbols, and > whether Valgrind can demangle them). gcj follows the C++ ABI conventions for mangling Java symbols, so the names may come out looking a little peculiar, but libiberty's demangle should handle them fine. <b -- Bryan O'Sullivan <bo...@se...> |