Salikh Zakirov wrote:
Evgueni Brevnov wrote:
Agree! It seems like a mess for me as well. The most clean approach is
to return EXCEPTION_CONTINUE_SEARCH for any exception happened in a
native code.
I recently found out the reason why smoke test gc.LOS hangs DRLVM on Windows
XP, and it turned out to be related to the hardware exception handling.
I can't believe we'll see this test running again :)
Since the fix will involve significant modifications to the file
vm/vmcore/src/util/win/ia32/nt_exception_filter.cpp,
I can do this modification too.
Good.
P.S. The reason of hang of gc.LOS is deadlock on a thread suspension:
Assume thread A handles NPE:
A1) segfault occured
A2) grab "system hwe lock" and call vectored_exception_handler
A3) instantiate NullPointerException object
A4) set up throwing NullPointerExceptionObject in the register snapshot
A5) return from vectored_exception_handler release "system hwe lock"
Let's next assume that garbage collection was started exactly when thread A
was in progress of running NullPointerException constructor. Then, thread A
will be suspended while still holding "system hwe lock".
Another thread B at that moment may be blocked on a "system hwe lock",
and since this lock is system and not known to Thread Manager, it just
waits forever for thread B to reach a safepoint.
This explains why this test doesn't hang on windows 2003 server SP1
(without SP1 the test hangs). I've seen this problem with system locking
some internal lock for VEH, and the fix for JVMTI is in HARMONY-1541.
Probably all parts of exception/signal handling should be changed to
this same trick - exit kernel to release the lock, and set EIP in
register context to point to the real VM exceptions handler.
--
Gregory
