Bug 265803 - suppress warnings w/o function or object names (in JITed code)
Summary: suppress warnings w/o function or object names (in JITed code)
Status: REPORTED
Alias: None
Product: valgrind
Classification: Developer tools
Component: general (show other bugs)
Version: 3.7 SVN
Platform: Unlisted Binaries Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-08 15:07 UTC by Konstantin Serebryany
Modified: 2011-02-08 17:27 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Konstantin Serebryany 2011-02-08 15:07:48 UTC
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.
Comment 1 Julian Seward 2011-02-08 17:10:47 UTC
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.
Comment 2 Andrew Haley 2011-02-08 17:27:30 UTC
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.