Menu
▾
▴
valgrind-users
|
From: Karl C. <ka...@cs...> - 2014-07-08 07:50:04
|
Hello, I am trying to get memcheck (valgrind-3.10.0.SVN) to run Jikes RVM (3.1.3+hg) on an x86_64-linux machine in 32-bit mode. However when I run: WRAP="valgrind --smc-check=all --undef-value-errors=no --workaround-gcc296-bugs=yes" rvm -wrap "$WRAP" -X:gc:eagerMmapSpaces=true HelloWorld I get a SIGSEGV in memcheck: ==10692== Memcheck, a memory error detector ==10692== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==10692== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info ==10692== Command: /home/karl/r/jikesrvm/dist/development_x86_64-linux/JikesRVM -X:ic=/home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.code.image -X:id=/home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.data.image -X:ir=/home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.rmap.image -X:vmClasses=/home/karl/r/jikesrvm/dist/development_x86_64-linux/jksvm.jar:/home/karl/r/jikesrvm/dist/development_x86_64-linux/rvmrt.jar -Duser.timezone=PDT -Djava.home=/home/karl/r/jikesrvm/dist/development_x86_64-linux -Dgnu.classpath.home.url=file:/home/karl/r/jikesrvm/dist/development_x86_64-linux -Dgnu.classpath.vm.shortname=JikesRVM -Duser.home=/home/karl -Duser.dir=/home/karl/r -Duser.name=karl -Dos.name=Linux -Dos.version=3.8.0-42-generic -Dos.arch=x86_64 -X:gc:eagerMmapSpaces=true HelloWorld ==10692== ==10692== Warning: client switching stacks? SP change: 0xfecf3a78 --> 0x42048468 ==10692== to suppress, use: --max-stackframe=1127565808 or greater ==10692== Warning: client switching stacks? SP change: 0x4f522d8 --> 0x50c43000 ==10692== to suppress, use: --max-stackframe=1271860520 or greater ==10692== Warning: client switching stacks? SP change: 0x57532d8 --> 0x50c87000 ==10692== to suppress, use: --max-stackframe=1263746344 or greater ==10692== further instances of this message will not be shown. --10692-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --10692-- si_code=1; Faulting address: 0x80000105; sp: 0x82d10c7c valgrind: the 'impossible' happened: Killed by fatal signal host stacktrace: ==10692== at 0x380660F4: vgPlain_get_StackTrace_wrk (m_stacktrace.c:324) ==10692== by 0x38066438: vgPlain_get_StackTrace (m_stacktrace.c:1441) ==10692== by 0x3804992F: record_ExeContext_wrk (m_execontext.c:341) ==10692== by 0x3801EFA4: vgMemCheck_set_allocated_at (mc_malloc_wrappers.c:305) ==10692== by 0x3801F349: create_MC_Chunk (mc_malloc_wrappers.c:203) ==10692== by 0x3801F69E: vgMemCheck_new_block (mc_malloc_wrappers.c:393) ==10692== by 0x3801F875: vgMemCheck_malloc (mc_malloc_wrappers.c:412) ==10692== by 0x380A7E5E: vgPlain_scheduler (scheduler.c:1783) ==10692== by 0x380BA357: run_a_thread_NORETURN (syswrap-linux.c:103) sched status: running_tid=1 Thread 1: status = VgTs_Runnable Looking at /proc/PID/maps shows that the faulting address (0x80000105) is not mapped, and is located right above the RVM's heap (which I hard coded to end at 0x80000000): ffcd5000-ffcf7000 rw-p 00000000 00:00 0 fecf3000-fecf5000 rw-p 00000000 00:00 0 85c12000-85e11000 rwxp 00000000 00:00 0 82e04000-8591d000 rwxp 00000000 00:00 0 82d11000-82d13000 ---p 00000000 00:00 0 82c11000-82d11000 rwxp 00000000 00:00 0 [stack:10692] 82c0f000-82c11000 ---p 00000000 00:00 0 829f6000-82c0f000 rwxp 00000000 00:00 0 8290f000-82977000 rwxp 00000000 00:00 0 8290e000-8290f000 rw-s 00000000 08:01 2756955 /tmp/vgdb-pipe-shared-mem-vgdb-10692-by-karl-on-??? 81e7b000-8290e000 rwxp 00000000 00:00 0 77400000-80000000 rwxp 00000000 00:00 0 50000000-77400000 rwxp 00000000 00:00 0 47000000-47056000 r--p 00000000 08:01 2501782 /home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.rmap.image 44000000-45062000 rwxp 00000000 08:01 2498986 /home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.code.image 40000000-420b0000 rwxp 00000000 08:01 2501780 /home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.data.image 38367000-39456000 rw-p 00000000 00:00 0 38364000-38367000 rw-p 00363000 08:01 4334855 /usr/local/lib/valgrind/memcheck-x86-linux 38000000-38364000 r-xp 00000000 08:01 4334855 /usr/local/lib/valgrind/memcheck-x86-linux 08060000-08061000 rwxp 00000000 00:00 0 0805f000-08060000 rw-p 00016000 08:01 2501798 /home/karl/r/jikesrvm/dist/development_x86_64-linux/JikesRVM 0805d000-0805f000 r--p 00014000 08:01 2501798 /home/karl/r/jikesrvm/dist/development_x86_64-linux/JikesRVM 08048000-0805d000 r-xp 00000000 08:01 2501798 /home/karl/r/jikesrvm/dist/development_x86_64-linux/JikesRVM 04352000-04752000 rwxp 00000000 00:00 0 0434d000-04352000 rw-p 00000000 00:00 0 0434c000-0434d000 rw-p 001a6000 08:01 1442032 /lib/i386-linux-gnu/libc-2.15.so 0434a000-0434c000 r--p 001a4000 08:01 1442032 /lib/i386-linux-gnu/libc-2.15.so 041a6000-0434a000 r-xp 00000000 08:01 1442032 /lib/i386-linux-gnu/libc-2.15.so 041a5000-041a6000 rw-p 0001c000 08:01 1442000 /lib/i386-linux-gnu/libgcc_s.so.1 041a4000-041a5000 r--p 0001b000 08:01 1442000 /lib/i386-linux-gnu/libgcc_s.so.1 04188000-041a4000 r-xp 00000000 08:01 1442000 /lib/i386-linux-gnu/libgcc_s.so.1 04187000-04188000 rw-p 00000000 00:00 0 04186000-04187000 rw-p 0002a000 08:01 1442027 /lib/i386-linux-gnu/libm-2.15.so 04185000-04186000 r--p 00029000 08:01 1442027 /lib/i386-linux-gnu/libm-2.15.so 0415b000-04185000 r-xp 00000000 08:01 1442027 /lib/i386-linux-gnu/libm-2.15.so 04154000-0415b000 rw-p 00000000 00:00 0 04153000-04154000 rw-p 000dc000 08:01 4070234 /usr/lib32/libstdc++.so.6.0.16 0414f000-04153000 r--p 000d8000 08:01 4070234 /usr/lib32/libstdc++.so.6.0.16 0414e000-0414f000 ---p 000d8000 08:01 4070234 /usr/lib32/libstdc++.so.6.0.16 04076000-0414e000 r-xp 00000000 08:01 4070234 /usr/lib32/libstdc++.so.6.0.16 04075000-04076000 rw-p 00001000 08:01 2501799 /home/karl/r/jikesrvm/dist/development_x86_64-linux/librvm.so 04074000-04075000 r--p 00000000 08:01 2501799 /home/karl/r/jikesrvm/dist/development_x86_64-linux/librvm.so 04073000-04074000 r-xp 00000000 08:01 2501799 /home/karl/r/jikesrvm/dist/development_x86_64-linux/librvm.so 04072000-04073000 rw-p 00003000 08:01 1442031 /lib/i386-linux-gnu/libdl-2.15.so 04071000-04072000 r--p 00002000 08:01 1442031 /lib/i386-linux-gnu/libdl-2.15.so 0406e000-04071000 r-xp 00000000 08:01 1442031 /lib/i386-linux-gnu/libdl-2.15.so 0406c000-0406e000 rw-p 00000000 00:00 0 0406b000-0406c000 rw-p 00017000 08:01 1442021 /lib/i386-linux-gnu/libpthread-2.15.so 0406a000-0406b000 r--p 00016000 08:01 1442021 /lib/i386-linux-gnu/libpthread-2.15.so 04053000-0406a000 r-xp 00000000 08:01 1442021 /lib/i386-linux-gnu/libpthread-2.15.so 04052000-04053000 rw-p 00000000 00:00 0 04051000-04052000 rw-p 00007000 08:01 1442023 /lib/i386-linux-gnu/librt-2.15.so 04050000-04051000 r--p 00006000 08:01 1442023 /lib/i386-linux-gnu/librt-2.15.so 04049000-04050000 r-xp 00000000 08:01 1442023 /lib/i386-linux-gnu/librt-2.15.so 04036000-04037000 rw-p 0000e000 08:01 4334857 /usr/local/lib/valgrind/vgpreload_memcheck-x86-linux.so 04035000-04036000 r--p 0000d000 08:01 4334857 /usr/local/lib/valgrind/vgpreload_memcheck-x86-linux.so 04027000-04035000 r-xp 00000000 08:01 4334857 /usr/local/lib/valgrind/vgpreload_memcheck-x86-linux.so 04026000-04027000 rw-p 00001000 08:01 4334750 /usr/local/lib/valgrind/vgpreload_core-x86-linux.so 04025000-04026000 r--p 00000000 08:01 4334750 /usr/local/lib/valgrind/vgpreload_core-x86-linux.so 04024000-04025000 r-xp 00000000 08:01 4334750 /usr/local/lib/valgrind/vgpreload_core-x86-linux.so 04022000-04024000 rw-p 00000000 00:00 0 04021000-04022000 rw-p 00020000 08:01 1442022 /lib/i386-linux-gnu/ld-2.15.so 04020000-04021000 r--p 0001f000 08:01 1442022 /lib/i386-linux-gnu/ld-2.15.so 04000000-04020000 r-xp 00000000 08:01 1442022 /lib/i386-linux-gnu/ld-2.15.so Any idea as to what's going on, or how I might debug the problem further? Any Valgrind flags or options I might be missing? The RVM runs fine on its' own, as well as in Nulgrind (and cachegrind and callgrind): $ WRAP="valgrind --tool=none" $ rvm -wrap "$WRAP" -X:gc:eagerMmapSpaces=true HelloWorld ==10877== Nulgrind, the minimal Valgrind tool ==10877== Copyright (C) 2002-2013, and GNU GPL'd, by Nicholas Nethercote. ==10877== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info ==10877== Command: /home/karl/r/jikesrvm/dist/development_x86_64-linux/JikesRVM -X:ic=/home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.code.image -X:id=/home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.data.image -X:ir=/home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.rmap.image -X:vmClasses=/home/karl/r/jikesrvm/dist/development_x86_64-linux/jksvm.jar:/home/karl/r/jikesrvm/dist/development_x86_64-linux/rvmrt.jar -Duser.timezone=PDT -Djava.home=/home/karl/r/jikesrvm/dist/development_x86_64-linux -Dgnu.classpath.home.url=file:/home/karl/r/jikesrvm/dist/development_x86_64-linux -Dgnu.classpath.vm.shortname=JikesRVM -Duser.home=/home/karl -Duser.dir=/home/karl/r -Duser.name=karl -Dos.name=Linux -Dos.version=3.8.0-42-generic -Dos.arch=x86_64 -X:gc:eagerMmapSpaces=true HelloWorld ==10877== Hello, World ==10877== Also, when I turn back on undef-value-errors in memcheck, it reports an invalid memory access / SIGSEGV: [ ... numerous "uninitialised values" in the RVM code image ... ] JikesRVM: TROUBLE. Got a signal (Segmentation fault; #11) from outside the VM's address space in thread 0x4350cc0. JikesRVM: UNRECOVERABLE trapped signal 11 (Segmentation fault) handler stack 41e84ab si->si_addr 0xccccccd1 cs 0x00000023 ds 0x0000002b es 0x0000002b fs 0x00000000 gs 0x0000000b ss 0x0000002b edi 0x04301a40 esi -- PR/VP 0x4203d277 ebp 0xcccccccd esp -- SP 0x4203cd40 ebx 0x0434bff4 edx 0x00000000 ecx 0x00000000 eax 0x04301a40 eip 0x041e84ab trapno 0x0000000e err 0x00000004 eflags 0x00000044 fpregs 4355f04 oldmask 0x00000000 cr2 0xccccccd1 fp0 0x00000000000000000000 fp1 0x00000000000000000000 fp2 0x00000000000000000000 fp3 0x00000000000000000000 fp4 0x00000000000000000000 fp5 0x00000000000000000000 fp6 0x00000000000000000000 fp7 0x00000000000000000000 JikesRVM: internal error ==11293== ==11293== Process terminating with default action of signal 11 (SIGSEGV) ==11293== Access not within mapped region at address 0xCCCCCCD1 Thanks, -Karl Cronburg- NB: This is a follow up to posting to the Jikes RVM mailing list (http://sourceforge.net/p/jikesrvm/mailman/message/32577482/) which led to the problem described in this email. |
|
From: Philippe W. <phi...@sk...> - 2014-07-08 18:05:04
|
On Tue, 2014-07-08 at 03:49 -0400, Karl Cronburg wrote: > Hello, > > I am trying to get memcheck (valgrind-3.10.0.SVN) to run Jikes RVM (3.1.3+hg) > on an x86_64-linux machine in 32-bit mode. However when I run: > > WRAP="valgrind --smc-check=all --undef-value-errors=no --workaround-gcc296-bugs=yes" > rvm -wrap "$WRAP" -X:gc:eagerMmapSpaces=true HelloWorld > > I get a SIGSEGV in memcheck: > > ==10692== Memcheck, a memory error detector > ==10692== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. > ==10692== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info > ==10692== Command: /home/karl/r/jikesrvm/dist/development_x86_64-linux/JikesRVM -X:ic=/home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.code.image -X:id=/home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.data.image -X:ir=/home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.rmap.image -X:vmClasses=/home/karl/r/jikesrvm/dist/development_x86_64-linux/jksvm.jar:/home/karl/r/jikesrvm/dist/development_x86_64-linux/rvmrt.jar -Duser.timezone=PDT -Djava.home=/home/karl/r/jikesrvm/dist/development_x86_64-linux -Dgnu.classpath.home.url=file:/home/karl/r/jikesrvm/dist/development_x86_64-linux -Dgnu.classpath.vm.shortname=JikesRVM -Duser.home=/home/karl -Duser.dir=/home/karl/r -Duser.name=karl -Dos.name=Linux -Dos.version=3.8.0-42-generic -Dos.arch=x86_64 -X:gc:eagerMmapSpaces=true HelloWorld > ==10692== > ==10692== Warning: client switching stacks? SP change: 0xfecf3a78 --> 0x42048468 > ==10692== to suppress, use: --max-stackframe=1127565808 or greater > ==10692== Warning: client switching stacks? SP change: 0x4f522d8 --> 0x50c43000 > ==10692== to suppress, use: --max-stackframe=1271860520 or greater > ==10692== Warning: client switching stacks? SP change: 0x57532d8 --> 0x50c87000 > ==10692== to suppress, use: --max-stackframe=1263746344 or greater > ==10692== further instances of this message will not be shown. > --10692-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting > --10692-- si_code=1; Faulting address: 0x80000105; sp: 0x82d10c7c > > valgrind: the 'impossible' happened: > Killed by fatal signal > > host stacktrace: > ==10692== at 0x380660F4: vgPlain_get_StackTrace_wrk (m_stacktrace.c:324) > ==10692== by 0x38066438: vgPlain_get_StackTrace (m_stacktrace.c:1441) > ==10692== by 0x3804992F: record_ExeContext_wrk (m_execontext.c:341) > ==10692== by 0x3801EFA4: vgMemCheck_set_allocated_at (mc_malloc_wrappers.c:305) > ==10692== by 0x3801F349: create_MC_Chunk (mc_malloc_wrappers.c:203) > ==10692== by 0x3801F69E: vgMemCheck_new_block (mc_malloc_wrappers.c:393) > ==10692== by 0x3801F875: vgMemCheck_malloc (mc_malloc_wrappers.c:412) > ==10692== by 0x380A7E5E: vgPlain_scheduler (scheduler.c:1783) > ==10692== by 0x380BA357: run_a_thread_NORETURN (syswrap-linux.c:103) > Any idea as to what's going on, or how I might debug the problem further? > Any Valgrind flags or options I might be missing? The RVM runs fine > on its' own, as well as in Nulgrind (and cachegrind and callgrind): >From what I can see, the above happens when Valgrind is not able to track properly the stack used by a thread. The 'switching stacks' messages very probably indicate that the jikes rvm does something special with stack. If that is the case, then usually the problem can be solved by adding client requests in the application code (the various VALGRIND_STACK_* client requests in valgrind.h). This might also happen due to the use of sigaltstack. It is unclear to me how to properly inform Valgrind of such alternate stack. In both case, basically, the problem is that valgrind believes that the stack goes from the current stack pointer value till the "last known stack base". When changing stack; this can include non addressable segments. The stack unwind code assumes however that everything is accessible between the current sp and the stack base. You might try to confirm the above by changing in m_stacktraces.c const Bool debug = False; to const Bool debug = True; and then be patient till you see the crash (as this will trace a lot for each unwind). Philippe |
|
From: Philippe W. <phi...@sk...> - 2014-07-08 18:48:49
|
On Tue, 2014-07-08 at 14:39 -0400, Eliot Moss wrote: > On 7/8/2014 2:04 PM, Philippe Waroquiers wrote: > > On Tue, 2014-07-08 at 03:49 -0400, Karl Cronburg wrote: > > I can confirm that Jikes RVM does it own special allocation > of stacks, which might be involved here. > > I am wondering why anyone would think a tool like memcheck > would work with a Java virtual machine like JikesRVM, with > its own notion of object, garbage collection, etc. For > example, JikesRVM almost certainly explicitly clears memory > before using it for objects, which would mean it is initialized, > and verified Java bytecode will never access an uninitialized > local variable. I suppose you might get some mileage on > checking JNI / native code stuff, but I'm not sure. So, > I am intrigued, but also wondering if maybe you're barking > up the wrong tree here ... > > Regards -- Eliot (Hi, Sam!) I guess memcheck could be useful for checking the RVM itself, not the Java code run by RVM. And maybe things like cachegrind/callgrind/helgrind might be useful ? Note that I have since a long time on my list of things to never do to look at defining client requests allowing a JIT compiler to indicate to Valgrind how to unwind and so make a reasonable "source" stacktrace of the JIT-ed code. Might make Valgrind a lot more interesting for mixed JIT code and JNI and 'virtual machine implementation' follow up. Philippe |
|
From: Karl C. <ka...@cs...> - 2014-07-08 19:48:02
Attachments:
smime.p7s
|
On 07/08/2014 02:48 PM, Philippe Waroquiers wrote: > On Tue, 2014-07-08 at 14:39 -0400, Eliot Moss wrote: >> On 7/8/2014 2:04 PM, Philippe Waroquiers wrote: >>> On Tue, 2014-07-08 at 03:49 -0400, Karl Cronburg wrote: >> >> I can confirm that Jikes RVM does it own special allocation >> of stacks, which might be involved here. >> >> I am wondering why anyone would think a tool like memcheck >> would work with a Java virtual machine like JikesRVM, with >> its own notion of object, garbage collection, etc. For >> example, JikesRVM almost certainly explicitly clears memory >> before using it for objects, which would mean it is initialized, >> and verified Java bytecode will never access an uninitialized >> local variable. I suppose you might get some mileage on >> checking JNI / native code stuff, but I'm not sure. So, >> I am intrigued, but also wondering if maybe you're barking >> up the wrong tree here ... >> >> Regards -- Eliot (Hi, Sam!) > I guess memcheck could be useful for checking the RVM itself, > not the Java code run by RVM. > And maybe things like cachegrind/callgrind/helgrind might be useful ? > > Note that I have since a long time on my list of things to never do > to look at defining client requests allowing a JIT compiler to > indicate to Valgrind how to unwind and so make a reasonable > "source" stacktrace of the JIT-ed code. > Might make Valgrind a lot more interesting for mixed JIT code and JNI > and 'virtual machine implementation' follow up. > > Philippe > > We're interested in using malloc/free client requests to see if we can get memcheck to tell us when the garbage collector is handling its' own memory incorrectly. -Karl- |
|
From: Karl C. <ka...@cs...> - 2014-07-09 11:48:15
|
On 07/08/2014 02:04 PM, Philippe Waroquiers wrote: > On Tue, 2014-07-08 at 03:49 -0400, Karl Cronburg wrote: >> Any idea as to what's going on, or how I might debug the problem further? >> Any Valgrind flags or options I might be missing? The RVM runs fine >> on its' own, as well as in Nulgrind (and cachegrind and callgrind): > > From what I can see, the above happens when Valgrind is not able to > track properly the stack used by a thread. > The 'switching stacks' messages very probably indicate that the jikes > rvm does something special with stack. > If that is the case, then usually the problem can be solved by adding > client requests in the application code (the various VALGRIND_STACK_* > client requests in valgrind.h). > > > This might also happen due to the use of sigaltstack. > It is unclear to me how to properly inform Valgrind of such alternate > stack. > > In both case, basically, the problem is that valgrind believes that the > stack goes from the current stack pointer value till the "last known > stack base". When changing stack; this can include non addressable > segments. The stack unwind code assumes however that everything is > accessible between the current sp and the stack base. You're right, this was the problem. I verified that the stack base pointer was way to large (right next to the SIGSEGV address). I've also found that everything runs fine when I add the "--keep-stacktraces=none" flag, which is acceptable for now since I'm more interested in the Java stack traces inside the RVM anyways. Thanks! -Karl- |
|
From: Eliot M. <mo...@cs...> - 2014-07-08 18:39:21
|
On 7/8/2014 2:04 PM, Philippe Waroquiers wrote: > On Tue, 2014-07-08 at 03:49 -0400, Karl Cronburg wrote: I can confirm that Jikes RVM does it own special allocation of stacks, which might be involved here. I am wondering why anyone would think a tool like memcheck would work with a Java virtual machine like JikesRVM, with its own notion of object, garbage collection, etc. For example, JikesRVM almost certainly explicitly clears memory before using it for objects, which would mean it is initialized, and verified Java bytecode will never access an uninitialized local variable. I suppose you might get some mileage on checking JNI / native code stuff, but I'm not sure. So, I am intrigued, but also wondering if maybe you're barking up the wrong tree here ... Regards -- Eliot (Hi, Sam!) |
|
From: Eliot M. <mo...@cs...> - 2014-07-08 20:15:02
|
On 7/8/2014 3:47 PM, Karl Cronburg wrote: > On 07/08/2014 02:48 PM, Philippe Waroquiers wrote: >> On Tue, 2014-07-08 at 14:39 -0400, Eliot Moss wrote: >>> On 7/8/2014 2:04 PM, Philippe Waroquiers wrote: >>>> On Tue, 2014-07-08 at 03:49 -0400, Karl Cronburg wrote: > We're interested in using malloc/free client requests to see if we can > get memcheck to tell us when the garbage collector is handling its' > own memory incorrectly. That sounds like a radical change to Jikes RVM. At present it doesn't really use malloc/free. It mmaps big chunks and manages them all itself, both for the system (i.e., outside of the garbage collected universe) and for the GC'ed heap. Best wishes -- EM |
|
From: Philippe W. <phi...@sk...> - 2014-07-08 23:20:19
|
On Tue, 2014-07-08 at 16:14 -0400, Eliot Moss wrote: > On 7/8/2014 3:47 PM, Karl Cronburg wrote: > > On 07/08/2014 02:48 PM, Philippe Waroquiers wrote: > >> On Tue, 2014-07-08 at 14:39 -0400, Eliot Moss wrote: > >>> On 7/8/2014 2:04 PM, Philippe Waroquiers wrote: > >>>> On Tue, 2014-07-08 at 03:49 -0400, Karl Cronburg wrote: > > > We're interested in using malloc/free client requests to see if we can > > get memcheck to tell us when the garbage collector is handling its' > > own memory incorrectly. > > That sounds like a radical change to Jikes RVM. At present it > doesn't really use malloc/free. It mmaps big chunks and manages > them all itself, both for the system (i.e., outside of the garbage > collected universe) and for the GC'ed heap. Valgrind has client requests that can be used to describe "user managed pool". These are a.o. used to run "valgrind in valgrind", so as to find valgrind bugs with itself. These requests are supposed to be general enough to describe most "user defined" memory pools Philippe |
Thanks for helping keep SourceForge clean.
X