RFR(S) 8209950: SIGBUS in CodeHeapState::print_names()

[Schmidt, Lutz]

HI Tobias, 

thanks for looking into this. And sure, I will (try to) explain what you requested. 

In sharedRuntime.cpp, method->signature is used in line
   2142:  ArgumentCount args(method->signature());
The ArgumentCount CTOR isn't ready to handle NULL pointers. I hit this issue while testing for JDK-8207343, after first applying the so far sufficient fix for JDK-8209588.

In codeHeapState.cpp, method->name() is not checked in the "big if statement", but a few lines further down (@ line 2198). Why? I did not want to skip the output, just because the name is unavailable. Plus, method->name() is only called if the method is active ("inuse" or "notused"), making it very unlikely for it'S name to be NULL. 

Could I answer your questions in sufficient detail? If no, please get back to me. 

Thanks,
Lutz

On 28.08.18, 09:10, "Tobias Hartmann" <tobias.hartmann at oracle.com> wrote:

    Hi Lutz,
    
    could you explain why you need to check method->signature() as well in sharedRuntime.cpp? And why is
    it then not necessary to check method->name()?
    
    Best regards,
    Tobias
    
    On 27.08.2018 14:30, Schmidt, Lutz wrote:
    > Dear all, 
    > 
    > may I please request reviews for my change? It hardens code which iterates over all nmethods in the code cache, e.g. by CodeCache::nmethods_do(). The bug refers to an issue in share/code/codeHeapState.cpp, but the same code exists in share/runtime/sharedRuntime.cpp. SIGBUS/SIGSEGV errors have been observed recently for both locations. Holding the CodeCache_lock while iterating, as asserted by CodeCache::nmethods_do(), does not help. 
    > 
    > The solution is to check yet another pointer for NULL and accessibility before actually using it. Not-NULL but invalid pointers have been observed. That makes accessibility checks necessary. The calls to os::is_readable_pointer() are potentially expensive (if they fail), but the alternative would be a SIGBUS/SIGSEGV.
    > 
    > This fix extends JDK-8209588 for the sharedRuntime.cpp part. As noted there, it may have impact as far back as jdk9 (for sharedRuntime.cpp). 
    > 
    > Bug:    https://bugs.openjdk.java.net/browse/JDK-8209950 
    > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8209950.00/ 
    > 
    > Thank you, 
    > Lutz
    > 
    >