RFR: 8332894: ubsan: vmError.cpp:2090:26: runtime error: division by zero

[Thomas Stuefe]

On Fri, 24 May 2024 13:30:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running with ubsan enabled on Linux x86_64, I get in the HS :tier1 tests this error :
> 
> runtime/ErrorHandling/TestDwarf_dontCheckDecoder.jtr
> 
> /jdk/src/hotspot/share/utilities/vmError.cpp:2090:26: runtime error: division by zero
>     #0 0x7f16bc531f32 in crash_with_sigfpe /jdk/src/hotspot/share/utilities/vmError.cpp:2090
>     #1 0x7f16bc531f32 in VMError::controlled_crash(int) /jdk/src/hotspot/share/utilities/vmError.cpp:2137
>     #2 0x7f16bea2d8fd in JNI_CreateJavaVM_inner /jdk/src/hotspot/share/prims/jni.cpp:3621
>     #3 0x7f16bea2d8fd in JNI_CreateJavaVM /jdk/src/hotspot/share/prims/jni.cpp:3672
>     #4 0x7f16c5dbd0e5 in InitializeJVM /jdk/src/java.base/share/native/libjli/java.c:1550
>     #5 0x7f16c5dbd0e5 in JavaMain /jdk/src/java.base/share/native/libjli/java.c:491
>     #6 0x7f16c5dc6748 in ThreadJavaMain /jdk/src/java.base/unix/native/libjli/java_md.c:642
>     #7 0x7f16c5d756e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 2f8d3c2d0f4d7888c2598d2ff6356537f5708a73)
>     #8 0x7f16c531550e in clone (/lib64/libc.so.6+0x11850e) (BuildId: f732026552f6adff988b338e92d466bc81a01c37)
> 
> Reason is that we do a float division by zero to get a signal . This is desired by us so not really an error but ubsan cannot know this.
> So add an attribute to this function that it has undefined behavior.
> See https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html   (division by zero) . "Floating point division by zero. This is undefined per the C and C++ standards"

@kimbarrett @MBaesken 

When this was written, the point was to raise a "real" SIGFPE. That matters because the behavior is subtly different from a real signal compared to one faked with raise (asynchronous vs synchronous).

Among other things, this SIGFPE is used for regression testing https://bugs.openjdk.org/browse/JDK-8065895. 

JDK-8065895 described a situation where we accidentally blocked all but the currently processed signal in the signal handler. That meant if we process a synchronous signal (e.g. SIGSEGV) and another, different, synchronous signal happens (e.g. SIGILL), the VM won't handle it in the secondary handler. Instead, depending on the OS, the process either dies immediately without core or it hangs in the kernel.

To regression-test the fix, we need to be able to trigger two different synchronous signals. I believe I used SIGILL and SIGSEGV in my original patch in the closed-source SAP JVM. Both are easy to trigger. But then I got resistance against triggering SIGILL, though, and therefore OpenJDK triggers SIGFPE instead of SIGILL. With the unfortunate effect that the test won't work as expected on all platforms.

Apart from JDK-8065895, it was also used to check hs-err printing in general. But I guess for that we could use a raised signal.

Replacing the triggering with raise will make the regression test for JDK-8065895 toothless. We may just as well remove it then. I remember it being a pain to investigate (no core, no hs-err file), so we should come up with a replacement.

We could replace it with an explicit check that tests that the signal handler masks inside error reporting are set up correctly. That is not the same as the real thing, but I guess it would be the next best thing.

If we keep it, we need a comment in controlled_crash, because this discussion re-occurs at regular intervals.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19394#issuecomment-2132079633