SDL2 & GDB: program received signal ?, unknown signal

Question

Let's start with description what's happening:

I'm playing with SDL2 library on Windows. I can compile programs using it, and when I run the .exe it works just fine. Problems arise when I try to debug it using GDB - when code comes to the SDL_Init or the SDL_OpenAudio functions (which possibly create new threads), GDB stops, shows "program received signal ?, unknown signal" message, and when I resume execution the program crashes.

Apparently there is a bug in GDB (https://www.mail-archive.com/[email protected]/msg149735.html) related to a thread naming, and it should be fixed in GDB version 7.11.1-1.

At first I was using GCC 5.1.0 (TDM) with GDB 7.6.1, so i decided to update to newer version. It looks that TDM doesn't provide any updates since about two years ago, so I installed MinGW-w64 (I don't remember now, but it might've been version 7.11 of GDB). Didn't help, GDB stil crashes.

Next I searched for newer version of GDB, and found 7.12 (www dot equation dot com/servlet/equation.cmd?fa=gdb). Didn't work, too, maybe fix didn't make it to this version.

Apparently this bug should be only present in x86 version of GDB, so I installed x64 version of TDM (GCC 5.1.0 and GDB 7.9.1). Program compiled fine, but GDB still catches unknown signal and program crashes.

Right now I effectively can't debug any program using SDL2. So, question is, what can I do to have it working again?

---

Possible solutions:

• Use Visual Studio - I like Eclipse (and that means I started to tolerate things i don't like in it) and don't really want to learn whole new IDE, but I'll keep that as last option.
• Compile GDB - tried that, didn't work, compiling things on Windows almost never works for me, and GDB 7.12 had this bug, too.
• Switch to Linux - Even more radical option than moving to Visual Studio.
• Fall back to SDL 1.2 - Things were easier back then...
• Switch to any other library - ...and hope they'll cooperate with GDB. That doesn't really sound like a solution.
• Switch to different compiler?
• Disable thread naming?

---

Code sample:

#include <SDL2/SDL.h>

// Normally I'd use #undef main
int WinMain(int, char**)
    {
    SDL_Init(SDL_INIT_EVERYTHING);

    return 0;
    }

Compilation: g++ gdbtest.cpp -lSDL2main -lSDL2

SDL2 version: 2.0.5 (latest build for Windows, MinGW, 32bit version)

---

Normal run: a.exe

Results: Program starts and ends normally

Running with GDB: Console log

Results: GDB receives unknown signal, program crashes

Answer 1

Ok, I think I found two ways of dealing with this. Source of problem lies in how GDB handles (or at least is supposed to handle) thread naming. To name a thread, one must raise exception with specific attributes. SDL2 does this in SDL_SYS_SetupThread function located in SDL2-2.0.5/src/thread/windows/SDL_systhread.c:168:

RaiseException(0x406D1388, 0, sizeof(inf) / sizeof(ULONG), (const ULONG_PTR*) &inf);

First option is to comment this line and recompile the library (well, compiling it is a problem in itself). Second option is to add:

SDL_SetHint(SDL_HINT_WINDOWS_DISABLE_THREAD_NAMING, "1");

somewhere early in code - in SDL_SYS_SetupThread function there is a call to SDL_GetHintBoolean that returns from function without naming anything if SDL_HINT_WINDOWS_... is false.

Still, finding way around this bug doesn't mean it won't come back to haunt me from some other library naming its threads.