Debugging X segfaults using SDL 2 on linux?

This is a bit odd, since it still works on windows, but on linux, apparently, something has changed in SDL 2 enough to make Qt crash when trying to create a Qt dialog.
The same code still works fine with SDL 1.2 on both platforms as well, so this is SDL 2 specific.
I am wondering, just what changed with the way SDL sets up X between 1.2 and 2.0 ? I know Xcursor was one thing different, but, it seems there is more to it ?
And I did try going back to using SDL_CreateCursor() instead of SDL_CreateColorCursor(), didn’t make a difference, same crash dump.

As soon as it hits show(), it segfaults with

Code:

GLIBC raw backtrace:
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf210)[0x7fd558e03210]
/lib/x86_64-linux-gnu/libpthread.so.0(pthread_mutex_lock+0x4)[0x7fd558dfdd54]
/usr/lib/x86_64-linux-gnu/libX11.so.6(XrmQGetResource+0x3c)[0x7fd555133d4c]
/usr/lib/x86_64-linux-gnu/libX11.so.6(XGetDefault+0xc2)[0x7fd555111752]
/usr/lib/x86_64-linux-gnu/libXcursor.so.1(_XcursorGetDisplayInfo+0x550)[0x7fd54e8a4af0]
/usr/lib/x86_64-linux-gnu/libXcursor.so.1(XcursorGetDefaultSize+0x9)[0x7fd54e8a4bc9]
/usr/lib/x86_64-linux-gnu/libXcursor.so.1(XcursorLibraryLoadCursor+0x15)[0x7fd54e8a6e55]
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x24d460)[0x7fd55632b460]
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(_ZNK7QCursor6handleEv+0x25)[0x7fd55632bae5]
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x2595a5)[0x7fd5563375a5]
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(_ZN14QWidgetPrivate10create_sysEmbb+0x1568)[0x7fd55633c2e8]
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(_ZN7QWidget6createEmbb+0x141)[0x7fd5562f2341]
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(_ZN7QWidget10setVisibleEb+0x30a)[0x7fd5562f8b0a]
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(_ZN7QDialog10setVisibleEb+0x5c)[0x7fd55675dedc]
./src/script(_ZN7QWidget4showEv+0x28)[0x68c64a]
[…]
0x68c64a QWidget::show()+40, [we call this…]
0x7fd55675dedc QDialog::setVisible(bool)+92,
0x7fd5562f8b0a QWidget::setVisible(bool)+778,
0x7fd55633c2e8 <QWidgetPrivate::create_sys(unsigned long, bool, bool)+5480>, 0x7fd5562f2341 <QWidget::create(unsigned long, bool, bool)+321>,
0x7fd55632bae5 <QCursor::handle() const+37>, 0x7fd5563375a5,
0x7fd54e8a6e55 <XcursorLibraryLoadCursor+21>, 0x7fd55632b460,
0x7fd54e8a4bc9 <XcursorGetDefaultSize+9>,
0x7fd54e8a4af0 <_XcursorGetDisplayInfo+1360>,
0x7fd555111752 <XGetDefault+194>,
0x7fd555133d4c <XrmQGetResource+60>,
0x7fd558dfdd54 <__GI___pthread_mutex_lock+4> [crash here]

Dump caused by signal: SIGSEGV: Invalid memory reference
__GI___pthread_mutex_lock (mutex=0x7fff8dfdf5d0)
at pthread_mutex_lock.c:50
Dump of assembler code for function __GI___pthread_mutex_lock:
[…]

So, it seems like this is a issue with something in X, correct ?
Any pointers on how to debug what the exact issue is ?

On the ML, I noticed it didn’t show
0x68c64a QWidget::show()+40, [we call this…]
0x7fd55675dedc QDialog::setVisible(bool)+92,
0x7fd5562f8b0a QWidget::setVisible(bool)+778,
0x7fd55633c2e8 <QWidgetPrivate::create_sys(unsigned long, bool, bool)+5480>, 0x7fd5562f2341 <QWidget::create(unsigned long, bool, bool)+321>,
0x7fd55632bae5 <QCursor::handle() const+37>, 0x7fd5563375a5,
0x7fd54e8a6e55 <XcursorLibraryLoadCursor+21>, 0x7fd55632b460,
0x7fd54e8a4bc9 <XcursorGetDefaultSize+9>,
0x7fd54e8a4af0 <_XcursorGetDisplayInfo+1360>,
0x7fd555111752 <XGetDefault+194>,
0x7fd555133d4c <XrmQGetResource+60>,
0x7fd558dfdd54 <__GI___pthread_mutex_lock+4> [crash here]

it shows
0x68c64a , [we call this…]
0x7fd55675dedc ,
0x7fd5562f8b0a ,
0x7fd55633c2e8 , 0x7fd5562f2341 ,
0x7fd55632bae5 , 0x7fd5563375a5,
0x7fd54e8a6e55 , 0x7fd55632b460,
0x7fd54e8a4bc9 ,
0x7fd54e8a4af0 <_XcursorGetDisplayInfo+1360>,
0x7fd555111752 ,
0x7fd555133d4c ,
0x7fd558dfdd54 <__GI___pthread_mutex_lock+4> [crash here]

instead ?

Is code tag broken on the ML ?
(this post is not using code tags as a test)

That also failed.
Looks like there is a filter in place…

Problem fixed, vexed sent me an e-mail on how to solve the issue.
For anyone else running into this, you must init SDL first, then go ahead and init Qt. Then all is fine.