Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8264798

exp_avg() throws SIGFPE, FPE_FLTDIV signal with floating point div by 0 zero signals enabled



    • Bug
    • Resolution: Won't Fix
    • P4
    • 21
    • None
    • hotspot
    • None
    • gc
    • x86_64
    • os_x


      I get a crash here:

      Current thread (0x00007fc21c025820): JavaThread "Unknown thread" [_thread_in_vm, id=8963, stack(0x000070000c4e2000,0x000070000c5e2000)]

      Stack: [0x000070000c4e2000,0x000070000c5e2000], sp=0x000070000c5e1d90, free space=1023k
      Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
      V [libjvm.dylib+0x944174] AdaptiveWeightedAverage::compute_adaptive_average(float, float)+0x7c
      V [libjvm.dylib+0x9441b8] AdaptiveWeightedAverage::sample(float)+0x32
      V [libjvm.dylib+0x956bf1] ThreadLocalAllocBuffer::initialize()+0x8f
      V [libjvm.dylib+0x6dcaf3] attach_current_thread(JavaVM_*, void**, void*, bool)+0x13d
      V [libjvm.dylib+0x6dc995] jni_AttachCurrentThread+0x28
      V [libjvm.dylib+0x6dc8ae] jni_DestroyJavaVM+0x48
      C [libjli.dylib+0x5200] JavaMain+0xc20
      C [libjli.dylib+0x7679] ThreadJavaMain+0x9
      C [libsystem_pthread.dylib+0x6109] _pthread_start+0x94
      C [libsystem_pthread.dylib+0x1b8b] thread_start+0xf

      siginfo: si_signo: 8 (SIGFPE), si_code: 1 (FPE_FLTDIV), si_addr: 0x0000000102544174

      on macOS, x86_64, if I enable floating point signals for div by 0, using:

      #include <xmmintrin.h>


      but only with a very specific combination of Xcode version and built inside Xcode, the normal jdk built using make does not reproduce. Any timing changes, like using a printf() affects the behavior and can make it go away.

      This looks like a bug in llvm compiler or macOS to me.

      The code in question is in gcUtil.hpp:

        static inline float exp_avg(float avg, float sample,
                                     unsigned int weight) {
          assert(weight <= 100, "weight must be a percent");
          return (100.0F - weight) * avg / 100.0F + weight * sample / 100.0F;

      and no division by zero is even possible here, still we get the crash and the signal SIGFPE, FPE_FLTDIV

      A workaround, which also makes the code, in my opinion, more readable and probably numerically more stable is to rewrite the code as:

        static inline float exp_avg(float avg, float sample,
                                     unsigned int weight) {
          assert(weight <= 100, "weight must be a percent");
          return ((100.0F - weight) * avg + weight * sample) / 100.0F;

      This is a nuisance issue more than anything, however, if the GC team would like to I can fix it.

      With this fix anyone can turn on floating point signals and potentially not get tripped - it's a tiny, but non zero chance they would.


        Issue Links



              Unassigned Unassigned
              gziemski Gerard Ziemski
              0 Vote for this issue
              3 Start watching this issue