nmethod::continuation_for_implicit_exception is not signal safe

XMLWordPrintable

    • Type: Bug
    • Resolution: Unresolved
    • Priority: P3
    • None
    • Affects Version/s: 8, 11, 17, 21, 25, 27
    • Component/s: hotspot
    • None

      `nmethod::continuation_for_implicit_exception` is called in the signal handler to find the continuation point we jump to after return from signal handling. It looks up the continuation PC in the implicit exception table. If it finds no continuation point, it does a printout on tty.

      That printout uses ResourceMark, either directly or indirectly. That, in turn, can lead to calls to malloc and free, as well as calls into NMT. That, in turn, could cause UL logging, more mallocs, and potentially locks. It also uses stringStream without a fixed buffer, which will also malloc. All things we really should not do during signal handling.

      In the current code, that can only ever happen for two error conditions:
      - a SIGSEGV occurred in JIT-compiled code, but there is no implicit NULL exception pc registered. So, admittedly, the JVM would crash in any case.
      - a SIGFPE or similar occurred in JIT-compiled code, but there is no divide by zero exception pc registered

      I am not sure the printout is really necessary. Printing to tty is certainly not ideal. We also log that an implicit exception occurred, with some basic information, in the EventLog. And we print the Machframes in the hs-err file. It would be nice if this printout could just be removed.

            Assignee:
            Unassigned
            Reporter:
            Thomas Stuefe
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: