RFR: 8079441: Intermittent failures on Windows with "Unexpected exit from test [exit code: 1080890248]" (0x406d1388)

[Thomas Stüfe]

Hi all,

sorry about this, I think I introduced setting the native windows thread
name. Note that this coding is present in our VM since over two years and
never caused any trouble. I did an extensive search in our (SAP) test
protocol databases, but could not find any traces of such crashes.

Nevertheless, I think the fix makes sense. If the error persists, it may
also be advisable just to remove the functionality for Windows altogether.
Although I like seeing the thread names in Visual Studio this feature is
not worth crashing over.

Kind Regards, Thomas


On Tue, Jan 10, 2017 at 11:14 AM, Robbin Ehn <robbin.ehn at oracle.com> wrote:

> Hi all, please review.
>
> We still have exit code 1080890248/0x406d1388 on windows when running
> kitchensink.
> Since this is the same value as windows thread name exception:
> http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx
> and we are still suspicious about this.
>
> This is not a bug fix per se, but it will determine if this exception is
> the cause of this
> and if so only when a debugger is attached this failure can happen.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8079441
>
> Tested with windbg and passes winx64 hotspot_jprt.
>
> /Robbin
>
> --- a/src/os/windows/vm/os_windows.cpp  Mon Jan 09 19:36:47 2017 +0000
> +++ b/src/os/windows/vm/os_windows.cpp  Tue Jan 10 11:00:45 2017 +0100
> @@ -777,6 +777,11 @@
>    // Note that unfortunately this only works if the process
>    // is already attached to a debugger; debugger must observe
>    // the exception below to show the correct name.
> +
> +  // If there is no debugger attached skip raising the exception
> +  if (!IsDebuggerPresent()) {
> +    return;
> +  }
>
>    const DWORD MS_VC_EXCEPTION = 0x406D1388;
>    struct {
>