RFR: JDK-8202319: Fix compilation warnings in Solaris debug builds for DevStudio 12.6 (original) (raw)

David Holmes david.holmes at oracle.com
Fri Apr 27 23:25:51 UTC 2018

We discussed this offline and Gary pointed out that, at least in the VMError case the attempt to SEGV by dereferencing zero is one of a specific number of crash inducing cases, others of which include trying to trigger SEGV at non-zero address and explicit signal raising. So changing the code to raise the signal directly is not really appropriate

So I am okay with just disabling the compilation warnings for these two cases.

Thanks, David

On 27/04/2018 6:59 PM, David Holmes wrote:

On 27/04/2018 4:48 PM, Kim Barrett wrote:

On Apr 27, 2018, at 2:11 AM, David Holmes <david.holmes at oracle.com> wrote:

On 27/04/2018 3:32 PM, Kim Barrett wrote: On Apr 26, 2018, at 6:49 PM, gary.adams at oracle.com wrote:

Adding build-dev and hotspot-runtime-dev aliases. -------- Forwarded Message -------- Subject:     RFR: JDK-8202319: Fix compilation warnings in Solaris debug builds for DevStudio 12.6 Date:     Thu, 26 Apr 2018 12:35:28 -0400 From:     Gary Adams <gary.adams at oracle.com> Reply-To:     gary.adams at oracle.com To:     OpenJDK Serviceability <serviceability-dev at openjdk.java.net>

Getting the sources ready for the next Solaris developer studio toolchain. Some additional warnings were found in the debug build. Issue:https://bugs.openjdk.java.net/browse/JDK-8202319 Webrev:http://cr.openjdk.java.net/~gadams/8202319/webrev.00/ This update conditionally disables some new error checks, if the new toolchain is used. I looked at these, and the warnings are correct, so just disabling them is a bit troubling. The thing is, the code in both cases is attempting to intentionally provoke a crash. But because the code is invoking undefined behavior, executing it might actually do anything, or nothing at all.  So while suppressing the warning might permit compilation, it’s not at all obvious that the compilation will produce anything like the desired code. And that’s also true for platforms that aren’t warning… True. Perhaps we should just raise a SEGV directly? David I like that idea. Hopefully this should work: os::signalraise(os::getsignalnumber("SEGV")); Cheers, David

More information about the build-dev mailing list