This is fixed in 2.0.1

GDB in MinGW 4.9.2 stops with "Unknown signal" "Got exception 0x406D1388" because same thing.

[line 175] in src/thread/windows/SDL_systhread.c
RaiseException(0x406D1388, 0, sizeof(inf) / sizeof(ULONG), (const ULONG_PTR*) &inf);

I used most recent (6ad89111cb4f) tarball from here (https://hg.libsdl.org/SDL/) which I built SDL2 myself. (./configure --prefix=..; make; make install)

Error happens on attempt to do SDL_Init() (In two apps of my project I doing Audio-only in editor or Everything in game engine)

P.S. Same OS Windows 7, same architecture x86_64.
On Linux and on OS X I have no troubles with debuggers.

P.P.S. Temporary to escape this trouble, I completely commented code in the SDL_SYS_SetupThread(const char *name) function, but at evening I'll try to look for fix myself if you will not fix that before me

Can confirm the same behavior with today's sources (2.0.4.10157), when trying to use gdb.
Please get rid of "RaiseException( 0x406D1388, ..)" : By design, this feature halts the program if any non-Microsoft debugger tries to run it. I don't see any good in it.

(In reply to yrizoud from comment #5)
> Can confirm the same behavior with today's sources (2.0.4.10157), when
> trying to use gdb.
> Please get rid of "RaiseException( 0x406D1388, ..)" : By design, this
> feature halts the program if any non-Microsoft debugger tries to run it. I
> don't see any good in it.

Or just put it under #ifdef _MSC_VER macros

(In reply to Vitaly Novichkov from comment #6)
> (In reply to yrizoud from comment #5)
> > Can confirm the same behavior with today's sources (2.0.4.10157), when
> > trying to use gdb.
> > Please get rid of "RaiseException( 0x406D1388, ..)" : By design, this
> > feature halts the program if any non-Microsoft debugger tries to run it. I
> > don't see any good in it.
> 
> Or just put it under #ifdef _MSC_VER macros

Builds of SDL can be used with Visual Studio if built with something else (as is the case with our official builds), and builds made with something else can be used in an app that is being debugged under Visual Studio.

(or debugged by something that isn't a traditional debugger, like gDebugger, in any case).


This is the current state of this issue:

- We thought we "fixed" it when Sam commented before. We've thought we fixed it like six or seven times now.  :)

- Since we can't actually fix it (we have to call RaiseException, we can't prevent debuggers from catching exceptions, etc) the latest in revision control sets you set a hint or environment variable at runtime to prevent the RaiseException call:

SDL_SetHint(SDL_HINT_WINDOWS_DISABLE_THREAD_NAMING, "1");

(or export the environment variable SDL_WINDOWS_DISABLE_THREAD_NAMING=1)

If you never intend to use Visual Studio on your app, you can just stick this call in main() and be done with it, or set it just when you use gDebugger, etc.

- As of the Windows 10 Creators Edition, there's an official win32 API for naming threads that doesn't need RaiseException, and we use it, but you need the latest OS release for it to be available and most tools don't support it (and older tools, like Visual Studio 2015 and earlier, never will), but eventually, this will be the preferred way to do things and we'll remove the RaiseException code entirely.

- Things like gDebugger should really just implement a check for this magic exception, but that's beyond my control.


Anyhow, you now have the power to work around the problem, so that's the best we can do until the new API gets more popular.

--ryan.

(In reply to Ryan C. Gordon from comment #7)
> (In reply to Vitaly Novichkov from comment #6)
> > (In reply to yrizoud from comment #5)
> > > Can confirm the same behavior with today's sources (2.0.4.10157), when
> > > trying to use gdb.
> > > Please get rid of "RaiseException( 0x406D1388, ..)" : By design, this
> > > feature halts the program if any non-Microsoft debugger tries to run it. I
> > > don't see any good in it.
> > 
> > Or just put it under #ifdef _MSC_VER macros
> 
> Builds of SDL can be used with Visual Studio if built with something else
> (as is the case with our official builds), and builds made with something
> else can be used in an app that is being debugged under Visual Studio.
> 
> (or debugged by something that isn't a traditional debugger, like gDebugger,
> in any case).
> 
> 
> This is the current state of this issue:
> 
> - We thought we "fixed" it when Sam commented before. We've thought we fixed
> it like six or seven times now.  :)
> 
> - Since we can't actually fix it (we have to call RaiseException, we can't
> prevent debuggers from catching exceptions, etc) the latest in revision
> control sets you set a hint or environment variable at runtime to prevent
> the RaiseException call:
> 
> SDL_SetHint(SDL_HINT_WINDOWS_DISABLE_THREAD_NAMING, "1");
> 
> (or export the environment variable SDL_WINDOWS_DISABLE_THREAD_NAMING=1)
> 
> If you never intend to use Visual Studio on your app, you can just stick
> this call in main() and be done with it, or set it just when you use
> gDebugger, etc.
> 
> - As of the Windows 10 Creators Edition, there's an official win32 API for
> naming threads that doesn't need RaiseException, and we use it, but you need
> the latest OS release for it to be available and most tools don't support it
> (and older tools, like Visual Studio 2015 and earlier, never will), but
> eventually, this will be the preferred way to do things and we'll remove the
> RaiseException code entirely.
> 
> - Things like gDebugger should really just implement a check for this magic
> exception, but that's beyond my control.
> 
> 
> Anyhow, you now have the power to work around the problem, so that's the
> best we can do until the new API gets more popular.
> 
> --ryan.

I think, is still be better to disable support for RaiseException for non-MSVC compilers by _MSC_VER macros. Not many people will guess that need to disable thread naming to escape this bug and will spend lot of time with this. Myself I prefer MinGW because GCC which a base of it, takes new C/C++ standards support much faster than MSVC, and most of my applications are incompatible with MSVC (the worst case is C++11 features in the templates support).

As a follow up, we ended up disabling the thread naming by default; the hint now defaults to disabling it, and Visual Studio users can enable it if they want.

--ryan.

This may be happening because the code to name threads by exception isn't correct. See this issue for why: https://developercommunity.visualstudio.com/content/problem/280049/native-code-setting-thread-name-causes-process-shu.html

You're supposed to wrap the RaiseException call in a try except handler:
__try{  
    RaiseException(MS_VC_EXCEPTION, 0, sizeof(info) / sizeof(ULONG_PTR), (ULONG_PTR*)&info);  
}  
__except (EXCEPTION_EXECUTE_HANDLER){  
}  

Without this the exception is just being thrown without anything to catch it if the debugger doesn't know about it.

I checked the commits for this code and the original code was very similar to this: https://github.com/SDL-mirror/SDL/commit/314ecabd38f35d84b4c60df5f1a642b5688ea9aa

Aside from using a different exception filter it's working as it should be there.

Later commits changed the try except to assembly code before being removed entirely in response to issue #2089.

My suggestion is to conditionally include the try except part as recommended by the MSDN docs if SDL is being compiled using the VC++ compiler. That should work for Windows targets compiled using the compiler that supports those keywords, while other compilers will work as they do now.

People who compile SDL using VC++ are likely to use the Visual Studio debugger as well so it should work properly, and the managed debugger won't take issue with it if the response given by the MS rep is to be believed.

Also, see https://stackoverflow.com/questions/7244645/porting-vcs-try-except-exception-stack-overflow-to-mingw

MinGW apparently doesn't understand structured exceptions so trying to use this code when SDL has been compiled with that could just crash the entire program anyway. That should probably be tested so this code doesn't cause problems during debugging.