[JBR11 + dcevm] when an agent retransform the start method of java.lang.Thread, the jvm crash about jetbrainsruntime HOT 8 CLOSED

I would still like to inquire about when this issue might be fixed.

That, of course, I cannot say at this point. What I can say with absolute certainty is the fix will come sooner if there's a simple reproducer for the bug. Ideally something like a script that, when executed, crashes the JVM in exactly this fashion.

from jetbrainsruntime.

The stacktrace alone doesn't ring a bell. Can you provide a reproducer?

Also, JBR11 is quite old. Is the problem reproducible with 17 or 21?

from jetbrainsruntime.

@mkartashev
I encountered a similar issue where the JVM crashes when starting with opentelemetry-javaagent.jar attached with -XX:+AllowEnhancedClassRedefinition parameter enabled. Removing the parameter resolves the issue. Here's my crash log:
replay_pid116783.log

I build my own JBR11 with the --with-debug-level=slowdebug parameter, and here's the crash log:
hs_err_pid174734.log

I just tested it and the crash issue also occurs on JBR17 (version jbr_jcef-17.0.9-linux-x64-b1000.47).
replay_pid175260.log

After debugging, I found that the issue was caused by agent retransforming well-known classes(java.* jdk.* sun.* etc), which led to an exception in the java_lang_Class assert is_instance method.

In my case (Java8 with dcevm patch), opentelemetry-javaagent.jar retransformed the java.lang.ClassLoader class, causing the classloader to lose all loaded classes. As a result, the native method findLoadedClass0 always return null(more details: dcevm/dcevm#215). I ported the commit that fixes the retransform well-known classes issue and encountered this problem (see commit for more details: HotswapProjects/openjdk-jdk8u-dcevm@654001b).

Hope this information is helpful. Please fix this issue as soon as possible. I'll try to port it to the dcevm8 project😆.

Best regards!

from jetbrainsruntime.

@AbsoluteZero-CHN Thanks for the detailed explanation! I will pass on to @skybber
FYI: the issue id in youtrack is JBR-6338, you can follow it there.

from jetbrainsruntime.

@AbsoluteZero-CHN Thanks for the detailed explanation! I will pass on to @skybber FYI: the issue id in youtrack is JBR-6338, you can follow it there.

I understand that this may be a foolish question, but I would still like to inquire about when this issue might be fixed. It is crucial for me as I have limited time left for my project 😣.

from jetbrainsruntime.

Although I acknowledge that this is not an ideal solution, I still want to share my approach here in the hope of providing some temporary workaround for those who are facing the same problem.

I have ported the code responsible for enhancing rt.jar from the opentelemetry-javaagent.jar to the openjdk source code (hard code), and then built a dedicated jdk for opentelemetry-javaagent.jar.
Next, in hotswap-agent.jar, I enhanced the source code of opentelemetry-javaagent.jar (ensuring that hotswap-agent.jar starts before opentelemetry-javaagent.jar) to make opentelemetry-javaagent.jar ignore the classes in rt.jar.
This way, opentelemetry-javaagent.jar does not need to enhance the classes in rt.jar, but can still make this part of the code effective.

Currently, this approach is working well for me. 😆

from jetbrainsruntime.

There is a jbr branch with the patch available at:

https://github.com/JetBrains/JetBrainsRuntime/tree/vladimir.dvorak/JBR-6363

if you know how to build a JDK, it would be great if you could try it on your case, but don't feel it's necessary

from jetbrainsruntime.

New jbr release https://github.com/JetBrains/JetBrainsRuntime/releases/tag/jbr-release-17.0.10b1186.1 support redefinition of java.lang.object, so this issue should be fixed now

from jetbrainsruntime.