| Summary: | suppress warnings w/o function or object names (in JITed code) | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Konstantin Serebryany <konstantin.s.serebryany> |
| Component: | general | Assignee: | Julian Seward <jseward> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | aph |
| Priority: | NOR | ||
| Version: | 3.7 SVN | ||
| Target Milestone: | --- | ||
| Platform: | Unlisted Binaries | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
I believe this is JVM generated code doing stack checks or otherwise poking the stack to check it won't overflow later (or some such). We've seen this stuff before. IIRC the distinguishing feature is that the accesses happen at an integral number of pages below the thread's stack pointer: -4096(%rsp), -8192(%rsp), etc. So you can easily hack up a patch for MC_(record_address_error) to identify and ignore these accesses. Look at the existing logic in that function for 'just_below_esp'; it should be trivial to derive what you need. That's exactly what it is. The JVM generates stack probes when it enters a context. If a probe segfaults a stack overflow exception is thrown; if not, the code generator knows that accesses below the probe will never fault. |
I've been running 'valgrind --smc-check=all' on a C++ program which has a Java plugin, i.e. at some point valgrind executes the JVM (OpenJDK). Some of the warnings coming from memcheck look like this: ==25756== Invalid write of size 4 ==25756== at 0x23E95648: ??? ==25756== by 0x23EFF137: ??? ==25756== Address 0x7ffeffade8 is not stack'd, malloc'd or (recently) free'd ==25756== { <insert_a_suppression_name_here> Memcheck:Addr4 obj:* obj:* } This is most likely some jited code executed by the JVM, but since valgrind did not manage to unwind the stack I can't even suppress it. I would prepare a patch in VG_(maybe_record_error) to hide such warnings, but please advice if there is a better way.