3 ms·
this crash is kind of interesting because i don't see any 'unsafe' code* in this getBounds() implementation so it shouldn't crash the JDK. like the code is brok
by benmmurphy 10y ago
this crash is kind of interesting because i don't see any 'unsafe' code* in this getBounds() implementation so it shouldn't crash the JDK. like the code is broken in how it works but it shouldn't be possible to muck around with threading a race and then call clone and crash the JDK.
* the code is very abstract and touches a lot of classes so there could be some unsafe code hiding there i can't see.
- brabel 10y agoIt seems to me that the main cause of the crash is the fact that the author used a special [classloader](https://github.com/vmlens/jcstress-examples/blob/master/src/main/java/com/vmlens/stressTest/util/StressTestClassLoader.java https://github.com/vmlens/jcstress-examples/blob/master/src/...) which always reloads the class and is not thread-safe intentionally (classloaders should be Thread-safe). I did not investigate in depth but that seems to be the main problem to me.
- ghusbands 10y agoIndeed, the memory model on ARM does not provide the same guarantees as x86. Given the behaviour described, it seems likely one could weaponise this kind of race condition, on ARM.