RFR(s): 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows
david.holmes at oracle.com
Thu Mar 12 02:45:45 UTC 2015
On 12/03/2015 8:03 AM, Thomas Stüfe wrote:
> Hi David,
> On Wed, Mar 11, 2015 at 9:43 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
> Hi Thomas,
> I'm not really familiar with Windows SEH. Won't this break custom
> launchers that already provide their own try/catch around Crate_JavaVM ?
> No. Windows SEH works stack based: any exception - e.g. a crash -
> between __try and __except will be handled by the handler given in the
> __except clause. Because they are stack based, they can be nested. If an
> exception is raised inside the inner __try/__except, first the inner
> handler is used, if that one feels not responsible, the next outer one
> and so on.
> With my fix, any exception raised inside CreateJavaVM will be handler by
> our handler topLevelExceptionFilter; only if our handler feels not
> responsible (returns EXCEPTION_CONTINUE_SEARCH), the user handler will
> be called.
My lack of knowledge about when our handler "feels responsible" still
leaves me a little nervous here. :)
> Any exception raised in the launcher itself outside of CreateJavaVM will
> still be handled by the user handler.
> (And I hate seeing the win32 ifdefs in the shared code :( ).
> Yes I know, I kind of expected that feedback :( - I did not find a
> better way of doing this. One could try to hide the __try/__except
> behind macros, but that would be kind of unwieldy and I don't like
> abstractiing something which only has meaning on one platform.
Does it help if we make the caller responsible for SEH and then put the
try/catch in the launcher code (hopefully in a windows specific part
> Kind regards, Thomas
> On 12/03/2015 1:40 AM, Thomas Stüfe wrote:
> Hi all,
> please review this smallish change:
> bug: https://bugs.openjdk.java.net/__browse/JDK-8074860
> This change adds SEH guards around JNI_CreateJavaVM(). Without
> the change,
> on Windows, the VM initialization runs without crash protection:
> will terminate VM immediately without writing an error log;
> also, any
> techniques relying on signals will not work, e.g. SafeFetch().
> This was partly solved before on a case-by-case base by wrapping
> sections which may crash in their own __try/__except wrappers -
> e.g. CPU
> feature probing.
> The change guards the whole of JNI_CreateJavaVM invocation in
> __try/__except. Unfortunately, for that to compile, I needed to
> introduce a
> wrapper around JNI_CreateJavaVM and move the whole of
> JNI_CreateJavaVM to a
> new function "JNI_CreateJavaVM_inner".
> This fix also gets rid of various workarounds which were used
> before to
> guard code sections.
> Thanks for reviewing!
> Oh, on a side note: I tried to figure out if threads which are
> from the outside via JNI AttachCurrentThread() are in any way
> guarded with
> SEH protection. Newly created threads are guarded because they
> run thru
> java_start() in os_windows.cpp, which adds SEH guards to all
> frames below.
> But for attached threads, I did not find any SEH guards - or
> maybe I am
> blind? What does that mean for java code running inside attached
> Thomas Stuefe
More information about the hotspot-runtime-dev