mirror of
https://github.com/corda/corda.git
synced 2025-01-23 04:48:09 +00:00
4a83b671b3
The problem (which we've only been able to reproduce consistently with the openjdk-src process=interpret build on Linux virtual machines) was a race condition during VM shutdown. Thread "A" would exit, see there were other threads still running and thus enter ZombieState, which involves acquiring and releasing a lock using RawMonitorResource. Then the last thread (thread "B") would exit, wait for thread "A" to release the lock, then shut down the VM, freeing all memory. However, thread "A" writes to its Thread object one last time after releasing the lock (in ~Resource, the destructor of the superclass of RawMonitorResource, which sets Thread::resource). If thread "B" frees that Thread before ~Resource runs, we end up writing to freed memory. Thus, we need to update Thread::resource before releasing the lock. Apparently C++ destructors run in order from most derived to least derived, which is not what we want here. My solution to split Resource into two classes, one that has no destructor and another that extends it (called AutoResource) which does hafe a destructor. Now all the classes which used to extend Resource extend AutoResource, except for RawMonitorResource, which extends Resource directly so it can control the order of operations. |
||
|---|---|---|
| .. | ||
| alloc-vector.h | ||
| append.h | ||
| arch.h | ||
| arm.h | ||
| bootimage.h | ||
| classpath-common.h | ||
| common.h | ||
| constants.h | ||
| embed.h | ||
| environment.h | ||
| finder.h | ||
| heapwalk.h | ||
| java-common.h | ||
| jnienv.h | ||
| lzma-util.h | ||
| lzma.h | ||
| machine.h | ||
| process.h | ||
| processor.h | ||
| target-fields.h | ||
| target.h | ||
| types.h | ||
| util.h | ||
| x86.h | ||
| zlib-custom.h | ||
| zone.h | ||