From: Robin G. <rob...@gm...> - 2014-07-06 08:13:51
|
Hi Karl, It looks like the address clash is at 81d00000, so try making Jikes RVM's maxumum mappable address lower than that ? Eg target.max-mappable.address=0x80000000 hth, Robin On 06/07/14 03:29, Karl Cronburg wrote: > Hello, > > My name is Karl Cronburg and I am a CS graduate student at Tufts > University. > > I am trying to get Jikes RVM 3.1.3+hg to run under valgrind-3.10.0.SVN > on an x86_64 Ubuntu machine. When I run this: > > WRAP="/usr/local/bin/valgrind --smc-check=all --error-limit=no > --workaround-gcc296-bugs=yes --log-file=/dev/null" > rvm -wrap "$WRAP" -X:gc:eagerMmapSpaces=true HelloWorld > > on a development_x86_64-linux build of Jikes, Jikes reports a > segmentation fault coming from outside the VM's address space: > > 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 0x620b1587 > ebp 0xcccccccd > esp -- SP 0x620b1050 > ebx 0x0434bff4 > edx 0x00019999 > ecx 0x00100000 > eax 0x04301a40 > eip 0x041e84ab > trapno 0x0000000e > err 0x00000004 > eflags 0x00000004 > 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 > > I subsequently tried rearranging Jikes' heap (as hinted at in the > userguide: http://jikesrvm.org/Running+the+RVM) by changing > build/targets/x86_64-linux.properties to contain: > > target.bootimage.code.address=0x34000000 > target.bootimage.data.address=0x30000000 > target.bootimage.rmap.address=0x37000000 > target.max-mappable.address=0xd0000000 > > This appears to get the VM off the ground (into Java), but it crashes on > a hardware exception (note that I turned on some debugging statements > to determine the kind of exception - a null pointer exception) after a > failed mmap: > > mmap (81d00000, 1048576, 7, 50, -1, 0) failed with 22: ensureMapped > failed with errno 22 on address 0x81d00000 > used = 13 pgs = boot 0 pgs + immortal 0 pgs + meta 0 pgs + los 0 pgs + > sanity 0 pgs + non-moving 5 pgs + sm-code 0 pgs + lg-code 0 pgs + > nursery 8 pgs + immix 0 pgs > used = 0.05 Mb = boot 0.00 Mb + immortal 0.00 Mb + meta 0.00 Mb + los > 0.00 Mb + sanity 0.00 Mb + non-moving 0.01 Mb + sm-code 0.00 Mb + > lg-code 0.00 Mb + nursery 0.03 Mb + immix 0.00 Mb > delivering hardware exception > we have a thread = 0x322bb0cc > it's in state = 1 > we have exception registers = 0x322bb594 > > Delivering exception trapCode=0 > Exception in the primordial thread "Jikes_RBoot_Thread" while booting: > JikesRVM: internal error: recursive use of hardware exception registers > (exiting) > -- Stack -- > (0x322cb528 21110) at [0x322cb528, 0x3503fe04] > Lorg/jikesrvm/scheduler/RVMThread; > handleUncaughtException(Ljava/lang/Throwable;)V at line 4725 > (0x322cb574 13821) at [0x322cb574, 0x35041403] > Lorg/jikesrvm/runtime/RuntimeEntrypoints; > handleUncaughtException(Ljava/lang/Throwable;)V at line 1072 > at [0x322cb574, 0x35041403] > Lorg/jikesrvm/runtime/RuntimeEntrypoints; > deliverException(Ljava/lang/Throwable;Lorg/jikesrvm/ArchitectureSpecific$Registers;)V > > > at line 1067 > (0x322cb5cc 13809) at [0x322cb5cc, 0x3502f328] > Lorg/jikesrvm/runtime/RuntimeEntrypoints; deliverHardwareException(II)V > at line 797 > (0x322cb5e8 1) at [0x322cb5e8, 0x3502f328] <hardware trap> > (0x322d3dec 21196) at [0x322d3dec, 0x350518a6] > Lorg/jikesrvm/scheduler/RVMThread; traceback(Ljava/lang/String;)V at > line 5075 > (0x322d3e08 7662) at [0x322d3e08, 0x34f33a5a] Lorg/jikesrvm/VM; > sysFail(Ljava/lang/String;)V at line 2325 > (0x322d3e4c 2853) at [0x322d3e4c, 0x35003af7] > Lorg/jikesrvm/mm/mmtk/Assert; fail(Ljava/lang/String;)V at line 41 > at [0x322d3e4c, 0x35003af7] Lorg/mmtk/utility/heap/Mmapper; > ensureMapped(Lorg/vmmagic/unboxed/Address;I)V at line 140 > (0x322d3e94 5557) at [0x322d3e94, 0x346fa2fe] Lorg/mmtk/policy/Space; > eagerlyMmapMMTkDiscontiguousSpaces()V at line 654 > (0x322d3eb0 982) at [0x322d3eb0, 0x346fbed5] Lorg/mmtk/policy/Space; > eagerlyMmapMMTkSpaces()V at line 613 > at [0x322d3eb0, 0x346fbed5] Lorg/mmtk/plan/Plan; processOptions()V > at line 231 > (0x322d3ee0 1043) at [0x322d3ee0, 0x3502354f] > Lorg/mmtk/plan/StopTheWorld; processOptions()V at line 61 > (0x322d3efc 14407) at [0x322d3efc, 0x35059e2b] > Lorg/jikesrvm/mm/mminterface/MemoryManager; postBoot()V at line 131 > (0x322d3f40 7484) at [0x322d3f40, 0x3505ac7e] Lorg/jikesrvm/VM; > finishBooting()V at line 202 > (0x322d3f58 7483) at [0x322d3f58, 0x08050406] Lorg/jikesrvm/VM; > boot()V at line 147 > > Any ideas on how I should arrange the heap? When I pause the program > using vgdb in valgrind, I get the following memory map in /proc/PID/maps. > > 04000000-04020000 r-xp 00000000 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 > 04021000-04022000 rw-p 00020000 08:01 1442022 > /lib/i386-linux-gnu/ld-2.15.so > 04022000-04024000 rw-p 00000000 00:00 0 > 04024000-04025000 r-xp 00000000 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 > 04026000-04027000 rw-p 00001000 08:01 4334750 > /usr/local/lib/valgrind/vgpreload_core-x86-linux.so > 04027000-04035000 r-xp 00000000 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 > 04036000-04037000 rw-p 0000e000 08:01 4334857 > /usr/local/lib/valgrind/vgpreload_memcheck-x86-linux.so > 04049000-04050000 r-xp 00000000 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 > 04051000-04052000 rw-p 00007000 08:01 1442023 > /lib/i386-linux-gnu/librt-2.15.so > 04052000-04053000 rw-p 00000000 00:00 0 > 04053000-0406a000 r-xp 00000000 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 > 0406b000-0406c000 rw-p 00017000 08:01 1442021 > /lib/i386-linux-gnu/libpthread-2.15.so > 0406c000-0406e000 rw-p 00000000 00:00 0 > 0406e000-04071000 r-xp 00000000 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 > 04072000-04073000 rw-p 00003000 08:01 1442031 > /lib/i386-linux-gnu/libdl-2.15.so > 04073000-04074000 r-xp 00000000 08:01 2637317 > /home/karl/r/jikesrvm/dist/development_x86_64-linux/librvm.so > 04074000-04075000 r--p 00000000 08:01 2637317 > /home/karl/r/jikesrvm/dist/development_x86_64-linux/librvm.so > 04075000-04076000 rw-p 00001000 08:01 2637317 > /home/karl/r/jikesrvm/dist/development_x86_64-linux/librvm.so > 04076000-0414e000 r-xp 00000000 08:01 4070234 > /usr/lib32/libstdc++.so.6.0.16 > 0414e000-0414f000 ---p 000d8000 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 > 04153000-04154000 rw-p 000dc000 08:01 4070234 > /usr/lib32/libstdc++.so.6.0.16 > 04154000-0415b000 rw-p 00000000 00:00 0 > 0415b000-04185000 r-xp 00000000 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 > 04186000-04187000 rw-p 0002a000 08:01 1442027 > /lib/i386-linux-gnu/libm-2.15.so > 04187000-04188000 rw-p 00000000 00:00 0 > 04188000-041a4000 r-xp 00000000 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 > 041a5000-041a6000 rw-p 0001c000 08:01 1442000 > /lib/i386-linux-gnu/libgcc_s.so.1 > 041a6000-0434a000 r-xp 00000000 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 > 0434c000-0434d000 rw-p 001a6000 08:01 1442032 > /lib/i386-linux-gnu/libc-2.15.so > 0434d000-04352000 rw-p 00000000 00:00 0 > 04352000-04752000 rwxp 00000000 00:00 0 > 08048000-0805d000 r-xp 00000000 08:01 2637316 > /home/karl/r/jikesrvm/dist/development_x86_64-linux/JikesRVM > 0805d000-0805f000 r--p 00014000 08:01 2637316 > /home/karl/r/jikesrvm/dist/development_x86_64-linux/JikesRVM > 0805f000-08060000 rw-p 00016000 08:01 2637316 > /home/karl/r/jikesrvm/dist/development_x86_64-linux/JikesRVM > 08060000-08061000 rwxp 00000000 00:00 0 > 30000000-3233b000 rwxp 00000000 08:01 2622283 > /home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.data.image > 34000000-35061000 rwxp 00000000 08:01 2622281 > /home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.code.image > 37000000-37056000 r--p 00000000 08:01 2622285 > /home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.rmap.image > 38000000-38364000 r-xp 00000000 08:01 4334855 > /usr/local/lib/valgrind/memcheck-x86-linux > 38364000-38367000 rw-p 00363000 08:01 4334855 > /usr/local/lib/valgrind/memcheck-x86-linux > 38367000-39456000 rw-p 00000000 00:00 0 > 81c7b000-8270e000 rwxp 00000000 00:00 0 > 8270e000-8270f000 rw-s 00000000 08:01 2754811 > /tmp/vgdb-pipe-shared-mem-vgdb-4005-by-karl-on-??? > 8270f000-82773000 rwxp 00000000 00:00 0 > 827f6000-82a0f000 rwxp 00000000 00:00 0 > 82a0f000-82a11000 ---p 00000000 00:00 0 > 82a11000-82b11000 rwxp 00000000 00:00 0 > [stack:4005] > 82b11000-82b13000 ---p 00000000 00:00 0 > 82c04000-8571d000 rwxp 00000000 00:00 0 > 85a12000-85c11000 rwxp 00000000 00:00 0 > fe8f2000-fe8f4000 rw-p 00000000 00:00 0 > ff8d3000-ff8f5000 rw-p 00000000 00:00 0 > > I've tried a few other memory arrangements and it has only ever resulted > in one of the two errors just described (external segmentation > fault, or mmap failed) or the RVM just hangs. > > Googling around I've found various posts / emails about getting Jikes to > run under Valgrind, as well as how the address space layout of the RVM > has been arbitrarily re-positioned over time to avoid libraries > (http://sourceforge.net/p/jikesrvm/mailman/message/29535725/). > > Thanks for your time, > -Karl Cronburg- > > > > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > > > > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > |