On Thu, 9 Jan 2025 19:23:07 GMT, Kevin Walls <kev...@openjdk.org> wrote:
> Hi, looks good. It is odd that this is never known to happen (zero ticks
> elapsed!) before, so we might wonder what ubsan is really changing here. But
> even if it only happens with ubsan, we can protect ourselves. 8-)
>
> (as long as we aren't changing too much to suit the tool -- we don't seem to
> be there yet!)
Running with ubsan just _shows_ the issue, but the issue is there also without
ubsan.
When running the test on macOS aarch64, product build and adding some check
like this
--- a/src/jdk.management/macosx/native/libmanagement_ext/UnixOperatingSystem.c
+++ b/src/jdk.management/macosx/native/libmanagement_ext/UnixOperatingSystem.c
@@ -31,6 +31,9 @@
#include "jvm.h"
+#include <assert.h>
+#include <stdlib.h>
+
JNIEXPORT jdouble JNICALL
Java_com_sun_management_internal_OperatingSystemImpl_getCpuLoad0
(JNIEnv *env, jobject dummy)
@@ -63,6 +66,11 @@
Java_com_sun_management_internal_OperatingSystemImpl_getCpuLoad0
jlong used_delta = used - last_used;
jlong total_delta = total - last_total;
+ //assert(total_delta != 0);
+ if (total_delta == 0) {
+ printf("total_delta is 0!\n");
+ exit(1);
+ }
then I see the printf output ` total_delta is 0! ` also in 'normal' non-ubsan
binaries when running javax/management/MBeanServer/OldMBeanServerTest.java .
We probably just lived so far with the fact that sometimes we divide in this
function by zero.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/23010#issuecomment-2582598969
