http://bugzilla.novell.com/show_bug.cgi?id=572372 http://bugzilla.novell.com/show_bug.cgi?id=572372#c10 --- Comment #10 from Petr Mladek <pmladek@novell.com> 2010-01-27 10:31:38 UTC --- Here are the Julian's findings: --- cut --- Re: valgrind reports that JDK writes to invalid memory address From: Julian Seward To: Petr Mladek, Kohei Yoshida, Thorsten Behrens Date: Yesterday 19:55:53 Greetings all, Grüße von Stuttgart, I managed to reproduce this problem. I noticed first that the invalid writes followed a sequence descending in page-size steps. Then I poked around a bit in V and discovered that they are all exactly at multiples of the page size below ESP/RSP. In the case of the test program, all the accesses are at one of the 6 following addresses: RSP - {1, 2, 3, 4, 5 or 6} * 4096 I'm pretty sure this isn't an accident. So I'd say you should close https://bugzilla.novell.com/show_bug.cgi?id=572372 as invalid. A couple of comments: (1) my feeling is that if we knew what the JRE is doing here, it might be possible to fix up Valgrind so as to make it more practical to Memcheck-ise a combined Java/C++ program. We'd have to see the JRE sources and figure out why it is poking pages below the stack pointer, though. Or perhaps -- and I suspect this is more likely -- it is generating code that pokes pages below the stack pointer. (2) Since the "invalid" accesses all occur 1 to 6 pages below SP, we can hack memcheck to ignore them. In memcheck/mc_errors.c, find this #define VG_GCC296_BUG_STACK_SLOP 1024 and change it to #define VG_GCC296_BUG_STACK_SLOP (4096 * 6) Rebuild, and re-run with --workaround-gcc296-bugs=yes. All the invalid accesses disappear! Although there are still a lot of uninitialised value errors. I don't know if these are related or not. The complete "patch" is below. I added a printf so you can see the sp relative offset for accesses which didn't get caught. Maybe you will have to adjust the magic 6 page number, I don't know. Anyway, good luck! So, don't forget --smc-check=all (because you're dealing with JIT- generated code) and --workaround-gcc296-bugs=yes to enable the kludg^H^H^H^H^Hfix as discussed above :-) J Index: memcheck/mc_errors.c =================================================================== --- memcheck/mc_errors.c (revision 11029) +++ memcheck/mc_errors.c (working copy) @@ -762,7 +762,8 @@ /* These many bytes below %ESP are considered addressible if we're doing the --workaround-gcc296-bugs hack. */ -#define VG_GCC296_BUG_STACK_SLOP 1024 +//#define VG_GCC296_BUG_STACK_SLOP 1024 +#define VG_GCC296_BUG_STACK_SLOP (4096 * 6) /* Is this address within some small distance below %ESP? Used only for the --workaround-gcc296-bugs kludge. */ @@ -820,7 +821,7 @@ user asks nicely, we just ignore it. */ if (MC_(clo_workaround_gcc296_bugs) && just_below_esp) return; - + VG_(printf)("XXXXXXXXXXX relative to SP: %ld\n", a - VG_(get_SP)(tid)); extra.Err.Addr.isWrite = isWrite; extra.Err.Addr.szB = szB; extra.Err.Addr.maybe_gcc = just_below_esp; --- cut --- -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.