JDK-8213483 : ARM32: runtime/ErrorHandling/ShowRegistersOnAssertTest.java jtreg test fail
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11,12,13,14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: aarch32
  • Submitted: 2018-11-07
  • Updated: 2024-11-22
  • Resolved: 2020-09-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 16
11.0.12Fixed 16 b17Fixed
Related Reports
Duplicate :  
JDK-8234967 - [test] ShowRegistersOnAssertTest fails on ARM32
Relates :  
JDK-8253167 - ARM32 builds fail after JDK-8247910
Description
Test says: java.lang.RuntimeException: '.*survived intentional crash.*' missing from stdout/stderr

Fail caused by hardware breakpoint that interrupts and stops java execution.

In the following call stack:
  CreateJavaVM -> VMError::test_error_handler -> VMError::controlled_crash ->
  guarantee -> BREAKPOINT -> __asm__ volatile ("bkpt")
the call to hardware breakpoint seems excessive:
+++ src/hotspot/cpu/arm/globalDefinitions_arm.hpp
#undef BREAKPOINT
#define BREAKPOINT __asm__ volatile ("bkpt")
Comments
Fix Request (11u): Patch doesn't apply cleanly, because of a different copyright year. This change fixes the mentioned testcase and removes the hardware breakpoints for win and 32-bit arm. Since the test case is a tier1 test case, I think it is more important to fix the issue and therefore the test case, than having real hardware breakpoint on two platforms. Webrev: https://cr.openjdk.java.net/~cgo/8213483/webrev.11u.01/ Review: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-April/005908.html The fix for this bug also fixes JDK-8253167, which is not relevant for 11u, but it will be backported at the same time.
22-04-2021
Changeset: bca9e55b Author: Kim Barrett <kbarrett@openjdk.org> Date: 2020-09-21 00:31:26 +0000 URL: https://git.openjdk.java.net/jdk/commit/bca9e55b
21-09-2020
Asserts can be disabled/skipped so an assert should not be followed by a hardware bkpt in general. Fatal errors on the other hand should never be expected to return, in which case a hardware bkpt is not unreasonable. On the other hand I can see why you would want the software ::breakpoint() in an assert that is being skipped (in terms of triggering an abort). So to me we have two distinct use cases for BREAKPOINT that perhaps need to be split? Though given only ARM and Win-32 define a hardware breakpoint this is probably not worth the effort.
20-09-2020
My reasons of removing BREAKPOINT macro redefinition was that - the BREAKPOINT macro redefinition doesn't make sense - the ShowRegistersOnAssertTest test doesn't work in fastdebug mode JDK-8253167 brings one more reason to remove macro redefinition: - asm statements are not allowed in constexpr functions in C++14
20-09-2020
Seeing this in tier1 on arm32. I think the test intentionally suppresses the assert, which makes the whole thing slide into BREAKPOINT. But I think there are only two places where BREAKPOINT is redefined. Here in breakpoint.hpp: // We presently only have one non-default definition, so it's not // worth going through the COMPILER_HEADER() dispatch, with all // non-visCPP files being empty. #ifdef TARGET_COMPILER_visCPP #ifndef _WIN64 #define BREAKPOINT __asm { int 3 } #endif // _WIN64 #endif // TARGET_COMPILER_visCPP ...and here in globalDefinitions_arm.hpp: #ifdef TARGET_COMPILER_gcc #ifdef ARM32 #undef BREAKPOINT #define BREAKPOINT __asm__ volatile ("bkpt") #endif #endif The affected test does not run on Windows, because: * @requires (vm.debug == true) & (os.family == "linux") ...so only ARM32 fails. I do believe Boris' patch that removes the hardware breakpoint is fine then: let the common definition be used for debugging: // If no more specific definition provided, default to calling a // function that is defined per-platform. See also os::breakpoint(). #ifndef BREAKPOINT extern "C" void breakpoint(); #define BREAKPOINT ::breakpoint() #endif
17-09-2019
We normally do not hit the BREAKPOINT because fatal errors never return. Without seeing the hs_err file I can't tell if we were deliberately forcing the VM to continue in this case. The hardware breakpoint has been in place for many, many years though there has been some debate as to its utility. But the basic idea is to not continue execution if a fatal error failed to terminate the VM.
08-11-2018
http://cr.openjdk.java.net/~bulasevich/8213483/webrev.00/
07-11-2018