Bug ID: JDK-8165358 vmassert_status is not debug-only

Versions (Unresolved/Resolved/Fixed)

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 10	JDK 9
10Fixed	9 b164Fixed

JDK-8148425 changed the expansion of vmassert_status from a direct use of vmassert (with a strerror call as an argument) to expanding into an if-qualified call to report_vm_status_error.  This new expansion should be, but is not, conditional on defined(ASSERT).  The old expansion didn't need such an explicit conditionalization; it relied on the conditionalization of the expansion of vmassert.

SQE is ok with fix. The regular testing should be enough to verify it.
20-03-2017
I could not find any bugs that might fit that description Chris. Thanks.
19-03-2017
> - potential for an assertion failure in product code This also means that during promotion testing of product builds, we might already be hitting asserts that aren't setting off alarms because the assert already has a bug filed against it, and the bug was not deemed critical enough to fix for 9.
19-03-2017
Fix request: This is a regression that was mis-prioritised when it was discovered and deferred to 10. It was re-discovered when an assertion fired in a product build (JDK-8176768) The bug causes a specific set of assertions to be active in product builds. This has three impacts: - code bloat of the binaries - additional runtime overhead for error checking - potential for an assertion failure in product code The fix is trivial and zero risk. It has already been reviewed: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-March/022860.html Reviewers: Dmitry Samersoff, Thomas Stuefe, Zhengyu Gu, Chris Plummer. Webrev: http://cr.openjdk.java.net/~dholmes/8165358/webrev/ The fix has been verified in the context of JDK-8176768 - no more assertion failures in product build.
19-03-2017
Impact: code bloat in product binary, performance overhead of additional error checking, possibility of asserting in product builds. M Likelihood: always present: H Workaround: none: H P2
18-03-2017

Duplicate :	JDK-8177072 - vmassert_status is active in product builds
Relates :	JDK-8148425 - strerror() function is not thread-safe