Segfault

[Rafael Winterhalter]

I can submit the bug, should I just send it to http://bugreport.java.com?

We cannot stablely reproduce the error, it happens in a customer
application during when updating a coroutine in a live application. To do
so, we run a Java agent that removes a class loader with all previous code
and creates a new class loader and hooks the new code into the user
application by appling retransformation. This causes of course a
significant amount of compilation.

2017-01-23 16:22 GMT+01:00 Volker Simonis <volker.simonis at gmail.com>:

> On Mon, Jan 23, 2017 at 1:01 PM, Tobias Hartmann
> <tobias.hartmann at oracle.com> wrote:
> > Hi Volker,
> >
> > On 20.01.2017 19:30, Volker Simonis wrote:
> >> Sorry for the previous mail - it was intended as a private answer to
> >> Rafael but I accidently also posted it to the list.
> >>
> >> But once it's public, here are the details:
> >>
> >> Rafael sent me hs_err file (together with replay) which looks exactly
> >> like https://bugs.openjdk.java.net/browse/JDK-8081379 which is a
> >> duplicate of https://bugs.openjdk.java.net/browse/JDK-8078262 which
> >> should be fixed with https://bugs.openjdk.java.net/browse/JDK-6675699
> >> (in 9 but also in  8u111b01).
> >
> > In the past, many loop optimization problems manifested as crashes in
> PhaseIdealLoop::build_loop_late_post(), including JDK-6675699 which I
> fixed some time ago in 9 and 8u.
> >
> > I would suggest to file a bug and attach the replay compilation and
> hs_err file. Were you able to reproduce this?
>
> This was reported by Rafael so I'll hand over to him :)
> I'll be happy to open a bug report with all the information he can provide.
>
> Regards,
> Volker
>
> >
> > Thanks,
> > Tobias
> >
> >> But the crash happened in 8.0_111-b14 (see below). If somebody is
> >> interested, I can open a new bug and attach the hs_err and replay
> >> file.
> >>
> >> Regards,
> >> Volker
> >>
> >> #
> >> # A fatal error has been detected by the Java Runtime Environment:
> >> #
> >> #  SIGSEGV (0xb) at pc=0x00007fe6aa553804, pid=6871,
> tid=0x00007fe685302700
> >> #
> >> # JRE version: Java(TM) SE Runtime Environment (8.0_111-b14) (build
> >> 1.8.0_111-b14)
> >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.111-b14 mixed mode
> >> linux-amd64 compressed oops)
> >> # Problematic frame:
> >> # V  [libjvm.so+0x818804]  PhaseIdealLoop::build_loop_
> late_post(Node*)+0x144
> >> #
> >> # Failed to write core dump. Core dumps have been disabled. To enable
> >> core dumping, try "ulimit -c unlimited" before starting Java
> >>  again
> >> #
> >> # If you would like to submit a bug report, please visit:
> >> #   http://bugreport.java.com/bugreport/crash.jsp
> >> #
> >>
> >> Stack: [0x00007fe685202000,0x00007fe685303000],
> >> sp=0x00007fe6852fd110,  free space=1004k
> >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
> C=native code)
> >> V  [libjvm.so+0x818804]  PhaseIdealLoop::build_loop_
> late_post(Node*)+0x144
> >> V  [libjvm.so+0x818dbc]  PhaseIdealLoop::build_loop_late(VectorSet&,
> >> Node_List&, Node_Stack&)+0x13c
> >> V  [libjvm.so+0x81b9d5]  PhaseIdealLoop::build_and_optimize(bool,
> bool)+0x835
> >> V  [libjvm.so+0x4a2ad0]  Compile::Optimize()+0xbe0
> >> V  [libjvm.so+0x4a5559]  Compile::Compile(ciEnv*, C2Compiler*,
> >> ciMethod*, int, bool, bool, bool)+0x13c9
> >> V  [libjvm.so+0x3f24f5]  C2Compiler::compile_method(ciEnv*, ciMethod*,
> >> int)+0x1f5
> >> V  [libjvm.so+0x4afb8a]
> >> CompileBroker::invoke_compiler_on_method(CompileTask*)+0xc9a
> >> V  [libjvm.so+0x4b0b36]  CompileBroker::compiler_thread_loop()+0x5d6
> >> V  [libjvm.so+0xa742b3]  JavaThread::thread_main_inner()+0x103
> >> V  [libjvm.so+0xa743fc]  JavaThread::run()+0x11c
> >> V  [libjvm.so+0x924ea8]  java_start(Thread*)+0x108
> >> C  [libpthread.so.0+0x7aa1]
> >>
> >>
> >> 2017-01-20 19:16 GMT+01:00 Volker Simonis <volker.simonis at gmail.com>:
> >>> Ja, das ist ganz klar ein C2 crash!
> >>>
> >>> Scheint das gleiche zu sein wie:
> >>> https://bugs.openjdk.java.net/browse/JDK-8081379 was wiederum ein
> >>> Duplikat von https://bugs.openjdk.java.net/browse/JDK-8078262 ist und
> >>> angeblich mit https://bugs.openjdk.java.net/browse/JDK-6675699 gefixt
> >>> wurde (auch in 8u111).
> >>>
> >>> Ich würde das man an hotspot-compiler-dev at openjdk.java.net schicken.
> >>>
> >>>
> >>> Zu unserem ursprünglichen Problem: ich glaube mittlerweile nicht mehr,
> >>> dass das Problem direkt mit Classentransormation zusammenhängt, da
> >>> diese an einem safepoint passiert. Weisst Du, ob parallel zur
> >>> Transformation auch viele Klassen geladen werden (entweder neue oder
> >>> generierte oder alte in einem neuen Classloader)?
> >>>
> >>>
> >>>
> >>> 2017-01-20 16:40 GMT+01:00 Rafael Winterhalter <rafael.wth at gmail.com>:
> >>>> Sorry, falsche Datei.
> >>>>
> >>>> ---------- Weitergeleitete Nachricht ----------
> >>>> Von: Rafael Winterhalter <rafael.wth at gmail.com>
> >>>> Datum: 20. Januar 2017 um 16:31
> >>>> Betreff: Segfault
> >>>> An: Volker Simonis <volker.simonis at gmail.com>
> >>>>
> >>>>
> >>>>
> >>>> Hei Volker,
> >>>> ich weiß nicht, ob das mit dem besprochenen Bug zusammenhängt aber die
> >>>> gleiche Routine verursacht mittlerweile ab und an den angehängten
> Fehler.
> >>>>
> >>>> Schaut mir aber eher aus als ob der JIT compiler (c2) zusammenfliegt.
> Ist
> >>>> das richtig? Schaut mir jedenfalls nach nem HotSpot bug aus.
> >>>>
> >>>> Vielleicht hilft's! Viele Grüße, Rafael
> >>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20170124/d456fec3/attachment-0001.html>