Segfault when redefining classes inside a class transformer about dcevm HOT 11 OPEN

You are using pretty old version. I did not remember if we had hotswap synchronization in devm8.161, could you try TravaOpenJDK or later dcevm versions ?

from dcevm.

You can find them at https://github.com/TravaOpenJDK/trava-jdk-8-dcevm/releases/tag/dcevm8u282b08

from dcevm.

You can find them at https://github.com/TravaOpenJDK/trava-jdk-8-dcevm/releases/tag/dcevm8u282b08

Tested, the crash still occurs. hs_err_pid17877.log

from dcevm.

I should note that it is very inconsistent - sometimes the crash happens on the VM thread, sometimes it's on the JDWP thread, and the stack dump in the crash log isn't always exactly the same.

from dcevm.

dcevm11 has the same problem?

from dcevm.

My program doesn't run in Java >8, so I'll have to see if I can make a minimum reproducible example on that version.

from dcevm.

Okay, I've tested it on Java 11. It works fine on standard OpenJDK 11 again, but with DCEVM 11 the JDWP Transport Listener thread now hangs.

"JDWP Transport Listener: dt_socket" #20 daemon prio=10 os_prio=0 cpu=46.37ms elapsed=52.16s tid=0x00007fbaf4519800 nid=0xc6e runnable  [0x00007fbab15ef000]
   java.lang.Thread.State: RUNNABLE
	at sun.instrument.InstrumentationImpl.redefineClasses0([email protected]/Native Method)
	at sun.instrument.InstrumentationImpl.redefineClasses([email protected]/InstrumentationImpl.java:193)
	at org.spongepowered.tools.agent.MixinAgent$Transformer.reApplyMixins(MixinAgent.java:121)
	at org.spongepowered.tools.agent.MixinAgent$Transformer.transform(MixinAgent.java:72)
	at java.lang.instrument.ClassFileTransformer.transform([email protected]/ClassFileTransformer.java:246)
	at sun.instrument.TransformerManager.transform([email protected]/TransformerManager.java:188)
	at sun.instrument.InstrumentationImpl.transform([email protected]/InstrumentationImpl.java:563)

from dcevm.

What is the initiator of transform method? Is it redefinition in IDE? Why do you need call redefineClasses from transform? In case of HA we trigger redefinition e.g. of proxies in separate thread and since proxiesdepends on result of previous redefinion.

from dcevm.

It's initiated by the IDE, yes.

The agent is Mixin, a framework for doing Java bytecode changes at runtime. These modifications are described using a "mixin" class, containing code which is injected into the target class. When transform-ing a mixin class, the javaagent is able to re-apply the transformations by using a saved copy of the target class' original bytecode, and then calls redefineClasses to update the target class. To the best of my knowledge there's no other way to implement this, as the target class isn't being redefined by the IDE (since from the IDE's perspective, the only thing that changed is the mixin class).

I can delay the redefinition of target classes by queuing them on a different thread, but that's bad for two reasons:

• There could be runtime errors if the old version of the target class references a member of some other class which was also removed, and would still be trying to access it before the second thread issues a reload
• There's no decent way (that I'm aware of) to detect when the IDE's redefinition is complete other than just setting the other thread to run after a fixed delay of some number of seconds. Redefining the classes from a different thread still causes a segfault if the initial reload is still running, so the only solution is to sleep for some number of seconds and hope it's enough (which is also needlessly slow).

from dcevm.

I've added a lock to jvmti enhanced redefinition. Most likely it causes deadlock now if redefinition calls instrumentation transformer and it calls redefinition. Lock is necessary since we have use cases with redefinition triggered from multiple sources, advanced redefinition does a lot of preparation stuff out of safepoint.

from dcevm.

Unfortunately there is no "redefinition" event in jvmti. It would be great to create an extension for it, even it seems to not be so complicated and it would be helpful for HotswapAgent since it also depends on time delays. Also it would be nice to move this thread to HotswapAgent, since dcevm8 project is "EOL"

from dcevm.