Seemingly the same issue, although I believe the X11 error is a side effect of it crashing.  Oddly enough when I get a backtrace..I get a different one every time.  


Program received signal SIGTERM, Terminated.
0xf7f89b30 in __nptl_create_event () from /usr/lib32/libpthread.so.0
(gdb) backtrace
#0  0xf7f89b30 in __nptl_create_event () from /usr/lib32/libpthread.so.0
#1  0xf7f8b8c8 in pthread_create@@GLIBC_2.1 () from /usr/lib32/libpthread.so.0
#2  0x09af7e5e in SpinPthread(unsigned long*, void* (*)(void*), unsigned int, unsigned int, void*) ()
#3  0x09af7f48 in FQueuedThreadMac::Create(FQueuedThreadPool*, unsigned int, unsigned int) ()
#4  0x09af8369 in FQueuedThreadPoolMac::Create(unsigned int, unsigned int, unsigned int) ()
#5  0x088bca2d in FEngineLoop::PreInit(wchar_t const*) ()
#6  0x088b7ffb in GuardedMain(wchar_t const*, void*, void*, int) ()
#7  0x09af5e32 in appMacCallGuardedMain() ()
#8  0x09aff23b in main ()


Program received signal SIGTERM, Terminated.
0x089e4b3a in appStristr(wchar_t const*, wchar_t const*) ()
(gdb) backtrace
#0  0x089e4b3a in appStristr(wchar_t const*, wchar_t const*) ()
#1  0x088b9099 in FString::InStr(wchar_t const*, unsigned int, unsigned int, int) const ()
#2  0x09aec6d8 in FFileManagerMac::Init(unsigned int) ()
#3  0x089f061e in appInit(wchar_t const*, FOutputDevice*, FOutputDeviceConsole*, FOutputDeviceError*, FFeedbackContext*, FFileManager*, FCallbackEventObserver*, FCallbackQueryDevice*, FConfigCacheIni* (*)()) ()
#4  0x088bcbf6 in FEngineLoop::PreInit(wchar_t const*) ()
#5  0x088b7ffb in GuardedMain(wchar_t const*, void*, void*, int) ()
#6  0x09af5e32 in appMacCallGuardedMain() ()
#7  0x09aff23b in main ()

#0  0x089f5a96 in FromAnsi(char) ()
(gdb) backtrace
#0  0x089f5a96 in FromAnsi(char) ()
#1  0x089eab50 in appBufferToString(FString&, unsigned char const*, int) ()
#2  0x089eac61 in appLoadFileToString(FString&, wchar_t const*, FFileManager*, unsigned int) ()
#3  0x09aec630 in FFileManagerMac::Init(unsigned int) ()
#4  0x089f061e in appInit(wchar_t const*, FOutputDevice*, FOutputDeviceConsole*, FOutputDeviceError*, FFeedbackContext*, FFileManager*, FCallbackEventObserver*, FCallbackQueryDevice*, FConfigCacheIni* (*)()) ()
#5  0x088bcbf6 in FEngineLoop::PreInit(wchar_t const*) ()
#6  0x088b7ffb in GuardedMain(wchar_t const*, void*, void*, int) ()
#7  0x09af5e32 in appMacCallGuardedMain() ()
#8  0x09aff23b in main ()


Other thread is inside pthread_wait

Forgot to mention, also on nvidia, 64bit arch linux.  


[user@archbang Binaries]$ ldd DungeonDefenders-x86 
	linux-gate.so.1 (0xf779d000)
	libpthread.so.0 => /usr/lib32/libpthread.so.0 (0xf7746000)
	libGL.so.1 => /usr/lib32/libGL.so.1 (0xf7666000)
	libSDL2-2.0.so.0 => /home/user/Downloads/DungeonDefenders/UDKGame/Binaries/libSDL2-2.0.so.0 (0xf758b000)
	libopenal.so.1 => /home/user/Downloads/DungeonDefenders/UDKGame/Binaries/libopenal.so.1 (0xf7540000)
	libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7456000)
	libm.so.6 => /usr/lib32/libm.so.6 (0xf7417000)
	libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf73fc000)
	libc.so.6 => /usr/lib32/libc.so.6 (0xf7252000)
	libdl.so.2 => /usr/lib32/libdl.so.2 (0xf724d000)
	/lib/ld-linux.so.2 (0xf779e000)
	libnvidia-tls.so.310.19 => /usr/lib32/libnvidia-tls.so.310.19 (0xf7248000)
	libnvidia-glcore.so.310.19 => /usr/lib32/libnvidia-glcore.so.310.19 (0xf5527000)
	libX11.so.6 => /usr/lib32/libX11.so.6 (0xf53f0000)
	libXext.so.6 => /usr/lib32/libXext.so.6 (0xf53de000)
	librt.so.1 => /usr/lib32/librt.so.1 (0xf53d5000)
	libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xf53b2000)
	libXau.so.6 => /usr/lib32/libXau.so.6 (0xf53ae000)
	libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf53a7000)

Yeah: I'd come to the conclusion that it's probably just a crash, too.

The FromAnsi/appBufferToString trace is showing up here, too, and there are other reported sightings of it over at HumbleBugs.

-- David

I've been having a bit more of a play with this, and there seem to be a couple of things going on.

Firstly, there are two subtly different issues: one where the game dies before the splash screen, and one where it dies afterwards. For me, these occur on different hardware (the former on intel, the latter on nVidia).

At some point when something thread-related is happening deep in the heart of pthreads (usually somewhere in clone() or __nptl_create_event()) a SIGTERM will be triggered. This is a bit unusual, usually crashes are more likely to be SIGSEGV or SIGFPE, so something slightly strange is going on.

These SIGTERMs are caught by libSDL's SDL_HandleSIG function, which promptly sends an SDL_QUIT message.

At a later point, when something Xlib related is happening, we get this IO error. (Set a breakpoint on _XIOError to catch this). It's pretty deterministic where this error hits: if the splash-screen has displayed, it's in x11_xinput2_poll within ManyMouse_PollEvent (deep within FFullscreenMovieBink::GameThreadPlayMovie) --- this is the same stack trace as in the original report.

Otherwise, if it crashes before the splash screen is displayed, it crashes in XineramaQueryScreens() from SDL_CreateWindow() in appShowSplashMac(). The full stack trace here is:
#0  0xf7a04b30 in _XIOError () from /usr/lib/i386-linux-gnu/libX11.so.6
#1  0xf7a0295e in _XReply () from /usr/lib/i386-linux-gnu/libX11.so.6
#2  0xf79090c5 in XineramaQueryScreens () from /usr/lib/i386-linux-gnu/libXinerama.so.1
#3  0xf7f06e75 in XineramaQueryScreens () from /home/david/Games/DungeonDefenders/UDKGame/Binaries/libSDL2-2.0.so.0
#4  0xf7f1846f in X11_GetDisplayBounds () from /home/david/Games/DungeonDefenders/UDKGame/Binaries/libSDL2-2.0.so.0
#5  0xf7ef6651 in SDL_GetDisplayBounds () from /home/david/Games/DungeonDefenders/UDKGame/Binaries/libSDL2-2.0.so.0
#6  0xf7efaf8f in SDL_CreateWindow () from /home/david/Games/DungeonDefenders/UDKGame/Binaries/libSDL2-2.0.so.0
#7  0xf7e9e847 in SDL_CreateWindowAndRenderer () from /home/david/Games/DungeonDefenders/UDKGame/Binaries/libSDL2-2.0.so.0
#8  0x09afde71 in appShowSplashMac() ()
#9  0x09af53df in appShowSplash(wchar_t const*) ()
#10 0x088b8099 in GuardedMain(wchar_t const*, void*, void*, int) ()
#11 0x09af5e32 in appMacCallGuardedMain() ()
#12 0x09aff23b in main ()


Hope at least something here is useful. Does anyone have fundamentally different symptoms?

-- David

same issue here:

/Games/DungeonDefenders/UDKGame/Binaries $ ./DungeonDefenders-x86
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
      after 153 requests (153 known processed) with 0 events remaining.

Linux Mint 14, 64bit, nvidia 313.09, 3.5.0-17-lowlatency kernel, xorg 1.13

Same on Slackware 64bit, linux-3.2.29, xorg 1.12.3, nvidia 310.19:

XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
      after 149 requests (149 known processed) with 0 events remaining.
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"

same story

XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
      after 223 requests (223 known processed) with 0 events remaining.
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
      after 18 requests (18 known processed) with 0 events remaining.


Linux gentoo, kernel 3.6.10-gentoo x86 PAE, xorg-server-1.13.0, ati-drivers-12.11_beta8

I get this error when launching from terminal. If I launch from Dolphin I get an error that kmserver could not be started and then the X server crashes.

Just thought I'd note that while these messages indeed indicate a bug, it has nothing to do with why the game fails to run. 

Looking at an strace, I see one thread being created then checking the time of day dozens of times, until it aborts itself shortly after failing to acquire a futex (timeout in ~16ms). Once that thread exits, the UI thread attempts to read three times from a socket which only held one message, which causes that message twice. Also note that EAGAIN is not a fatal error at all. 

I've been unable to identify what causes this game to fail, aside from case mismatches in filenames which I have compensated for. It wasn't enough.

The problem is because the launcher tries to find /usr/bin/gnome-screensaver-command and fails after it.

So the actual fix for this problem if making the launcher doesn't find it or continues if it was not found, as obviously a lot of us are not gnome users..

For a workaround, just use this command:
# ln -s /bin/true /usr/bin/gnome-screensaver-command

source: phoronix foruns

The symlink of /usr/bin/true to gnome screensaver worked for me.

confirming, symlink fixes the issue.
game works fine (except the damn gamespy which throws unknown errors on log in -but thats another issue report)

*** Bug 5824 has been marked as a duplicate of this bug. ***

Thanks: that works a treat! The game now works fine on my nVidia box, and hits #5823 on my intel box.

I've reported this over at the SDL bugtracker, with a patch:
http://bugzilla.libsdl.org/show_bug.cgi?id=1670

[Man, bugzilla's been a bit dodgy this morning -- I tried to post this hours ago ]

-- David

A user reported that now the xbox 360 controller does not work (a feature in the game on pc)

(In reply to comment #10)
> The problem is because the launcher tries to find
> /usr/bin/gnome-screensaver-command and fails after it.
> 
> So the actual fix for this problem if making the launcher doesn't find it or
> continues if it was not found, as obviously a lot of us are not gnome users..
> 
> For a workaround, just use this command:
> # ln -s /bin/true /usr/bin/gnome-screensaver-command
> 
> source: phoronix foruns

I also confirm this bug.
Making symlink to /usr/bin/gnome-screensaver-command helps.

Ubuntu 12.04 amd64

This is fixed in the next build.

If anyone is bored, you can build the latest SDL2 from http://hg.libsdl.org/SDL where the actual fix was made. The next build will have an updated SDL2.

--ryan.

Given the size of the game, will there be a "patch" release? I imagine only libSDL and the game's executable are likely to change.

(In reply to comment #15)
> A user reported that now the xbox 360 controller does not work (a feature in
> the game on pc)

Separate bug reports are really helpful, please, or these likely get forgotten when I close this bug report.

(We have this particular problem as Bug #5837, fwiw; feel free to CC yourself on that bug if you like!)

--ryan.

(In reply to comment #18)
> Given the size of the game, will there be a "patch" release? I imagine only
> libSDL and the game's executable are likely to change.

Yes, we'll do it like Psychonauts (an updated complete installer, plus a tarball of the handful of small changed files).

--ryan.

*** Bug 5846 has been marked as a duplicate of this bug. ***

*** Bug 5852 has been marked as a duplicate of this bug. ***

*** Bug 5871 has been marked as a duplicate of this bug. ***

*** Bug 5864 has been marked as a duplicate of this bug. ***

Marking several bugs as FIXED. There's a new build for the new Humble Bundle that resolves this issue. Log in to your Humble Bundle account and redownload the game to get the latest version.

(I'll put up a set of files that represent the difference between the two builds; they added more DLC since the first bundle, so you're going to have to download a few hundred megabytes, but it's better than a 5+ gigabytes. I'll try to do that tomorrow.)

--ryan.