byte-buddy icon indicating copy to clipboard operation
byte-buddy copied to clipboard

Consider compatibility, mainly for jdk8 known bugs

Open sgy-zihan opened this issue 2 years ago • 3 comments

At first, I raised a double free question to bytebuddy, and later confirmed that it was a jdk bug, but a very difficult problem is that the reason for this bug is that the redefineClass of jvm in 1.8 and the implementation of class unloading are caused. The class generated in the redefineClass stage is considered by jvm to be a temporary class. If the temporary class does not reach the final conversion stage, it will be destroyed by jvm. The reference relationship with the temporary class, which leads to a small probability of double free, the main scenario is in the restranform stage, if the class conversion fails and the class loader mechanism is used, the temporary class recycling phenomenon will occur, because some reference relationships exist, and the original class must be recycled, and the jvm does not check, resulting in repeated releases, and then there is a certain probability that double free will occur, and the entire jvm will hang. I think bytebuddy can consider compatible with this scenario, this is a known bug The jdk list can be found, and almost all instrumentation technologies are inevitable, but bytebuddy is the most affected, because bytebuddy uses a large number of custom class loaders for code processing, and this is an option in asm, which is not required. It is a mandatory item in bytebuddy, which means there is no option. I hope bytebuddy will consider some versions of jdk8 that have not fixed this problem and do some compatibility. At present, javassist technology and asm are more likely to trigger this problem than bytebuddy Small, byetbuddy is easy to trigger, but others need a lot of transform to see

sgy-zihan avatar Jul 21 '23 15:07 sgy-zihan

This problem often occurs when the agent converts the code, mainly due to the following situations during the conversion phase, class definition errors, class loading errors, or a large number of classloader operation behaviors and a large number of dynamic class creation, currently it seems that bytebuddy is more likely to trigger

sgy-zihan avatar Jul 21 '23 15:07 sgy-zihan

Yes, there must have been many severe transform behaviors

sgy-zihan avatar Jul 21 '23 15:07 sgy-zihan

Can you give me a pointer to this documented bug? How could it be avoided?

raphw avatar Jul 23 '23 06:07 raphw