david@Miho:/opt/SuperMeatBoy$ ./SuperMeatBoy
Super Meat Boy: Installed in '.'.
Super Meat Boy: Using x86 version.
Segmentation fault
david@Miho:/opt/SuperMeatBoy$
It opens a large black window and then after a couple seconds, the window dies and it prints a segmentation fault.
Installed from Humble Indie Bundle #4
(supermeatboy-linux-12132011b-bin)
OS:
Debian GNU/Linux 5.0
ATI Catalyst 9.3
Pentium-M 2.0 Ghz
ATI Radeon Mobility X700
I can confirm this bug in 64-bit Ubuntu (10.04 with glibc updated to 2.14.1) as well. It insta-segfaults when using the 64 bit version, and a black window appears for a couple seconds before segfaulting when using linux32 to make it think it is 32 bit.
dopefish7590@Angelfire:~/apps/supermeatboy <('.'<)$ ./SuperMeatBoy
Super Meat Boy: Installed in '.'.
Super Meat Boy: Using amd64 version.
Segmentation fault
dopefish7590@Angelfire:~/apps/supermeatboy ^('.')^$ linux32 !!
linux32 ./SuperMeatBoy
Super Meat Boy: Installed in '.'.
Super Meat Boy: Using x86 version.
Segmentation fault
dopefish7590@Angelfire:~/apps/supermeatboy (>'.')>$ ./amd64/SuperMeatBoy-amd64
Segmentation fault
dopefish7590@Angelfire:~/apps/supermeatboy ^('.')^$ ./x86/SuperMeatBoy-x86
Segmentation fault
And here is some interesting output from strace:
mkdir("", 0700) = -1 ENOENT (No such file or directory)
mkdir("/home", 0700) = -1 EEXIST (File exists)
mkdir("/home/dopefish7590", 0700) = -1 EEXIST (File exists)
mkdir("/home/dopefish7590/.local", 0700) = -1 EEXIST (File exists)
mkdir("/home/dopefish7590/.local/share", 0700) = -1 EEXIST (File exists)
mkdir("/home/dopefish7590/.local/share/SuperMeatBoy", 0700) = -1 EEXIST (File exists)
mkdir("/home/dopefish7590/.local/share/SuperMeatBoy/UserData", 0700) = -1 EEXIST (File exists)
mkdir("/home/dopefish7590/.local/share/SuperMeatBoy/UserData/", 0700) = -1 EEXIST (File exists)
Isn't the last one supposed to be a file in the folder?
When I link something else there, 32 bit suddenly starts insta-segfaulting. Since this directly affects the behavior of the bug, I think it may be related.
Confirmed on x86 with free (ATi) graphics drivers.
Confirmed NOT HAPPENING (game runs fine) on x86_64 with proprietary nVidia graphics drivers.
Someone also mentioned using Intel graphics and experiencing this bug. Which graphics drivers are you using?
syscall traces aren't generally useful; can someone please give me a stack trace?
Run the game under gdb:
# Replace "amd64" with "x86" for the 32-bit version...
cd /where/i/installed/supermeatboy/amd64
gdb ./SuperMeatBoy-amd64
# at the gdb prompt, run the game...
r
# when it crashes, get the stack trace...
bt
# Quit gdb
q
Cut and paste the output from the "bt" command here.
Thanks!
--ryan.
Mine is pretty much identical, except it's got an extra line at the top.
[Thread 0xa3d3bb70 (LWP 3862) exited]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb740f6d0 (LWP 3824)]
0x000010d1 in ?? ()
(gdb) bt
#0 0x000010d1 in ?? ()
#1 0x08191808 in impl_GLSL_CompileShader ()
#2 0x08193500 in MOJOSHADER_glCompileShader ()
#3 0x081c0aae in CreateOpenGLShader ()
#4 0x082a4923 in Shader::CreateShader ()
#5 0x08288f2e in FragmentLinker::GetShader ()
#6 0x081bffc9 in gfxDraw ()
#7 0x0828ab90 in TGraphics::Draw ()
#8 0x082721bf in FlashSymbol::Render ()
#9 0x08274f33 in FlashLibraryInstance::TimelineRender ()
#10 0x08275339 in FlashTimeline::Render ()
#11 0x0827543b in FlashMovieClip::Render ()
#12 0x08274f33 in FlashLibraryInstance::TimelineRender ()
#13 0x08275339 in FlashTimeline::Render ()
#14 0x0827543b in FlashMovieClip::Render ()
#15 0x0826f37e in FlashLibraryInstance::Render ()
#16 0x0810e754 in GSMBMenu::RenderTitleScreenForIntro ()
#17 0x080b49ff in GMeatHUD::Render ()
#18 0x0829bfeb in RenderLayers::Render ()
#19 0x08281b7d in TEngine::Render ()
#20 0x08281e5b in TEngine::EngineRun ()
#21 0x08281fd1 in TEngine::Run ()
#22 0x080a90be in main ()
(gdb)
Comment 12Fibonacci Prower
2011-12-15 15:39:09 EST
I'm attaching four files: an strace and an ltrace, in a system in which the game runs (64-bit, nVidia drivers) and a system in which it doesn't (32-bit, free ATi drivers).
The ltraces had to be gzipped because they were too big.
Comment 13Fibonacci Prower
2011-12-15 15:47:11 EST
(In reply to comment #15)
> And the ltraces were too big even after gzipping, so I cannot show them here.
Again, these aren't usually helpful anyhow.
--ryan.
So the consensus seems to be that this is crashing in the GLSL compiler. I suppose we could try kicking the game over to ARB programs instead of GLSL shaders and see if it helps.
--ryan.
This does not happened with 64bit of Linux and Mesa driver.
Tested on:
Ubuntu 11.10
Linux 3.1.5-030105-generic
Mesa 7.11.2
Mesa compiled by myself by -m64 option. So I dont know why 32bit get segfault while 64 bit not.
Tested on Intel GMA 4500.
The game runs fine with this graphics card and 64bit Linux and Mesa.
Thank you
This does not happened with 64bit of Linux and Mesa driver.
Tested on:
Ubuntu 11.10
Linux 3.1.5-030105-generic
Mesa 7.11.2
Mesa compiled by myself by -m64 option. So I dont know why 32bit get segfault while 64 bit not.
Tested on Intel GMA 4500.
The game runs fine with this graphics card and 64bit Linux and Mesa.
Thank you
Google search suggests that compiling mesa for 64-bit also disables the x86 assembly optimizations because some newer 64-bit CPUs no longer support the older assembly optimizations (3DNOW, MMX,etc.).. Not sure if that's still true in the latest builds of mesa, but that would explain it..
Also, as I noted in the other thread. If the user is missing hardware/driver support for the OpenGL extension in question.... It looks like Mesa is returning a non-null pointer to garbage if it was compiled with ASM optimizations, while with ASM optimizations when MESA was compiled, Mesa returns a null pointer..
The game is trying to use the extension whenever the pointer is not null, hence the crash. Mesa team says the game must always check for support of the OpenGL extension and not rely on returned pointers being NULL as a non-null pointer does not indicate hardware/driver support for the OpenGL extension.
It looks like MESA added support for GL_ARB_transform_feedback2 back in 2010... So if your graphics driver is older than 18 months *AND* you are running a 32-bit OS where your distro compiled Mesa with assembly optimizations, you will get a segfault in this game (and also Shank) until the games get patched.
The problem is that Mojoshader looks for the function called "glCreateShaderObject" which doesn't exist in OpenGL - it should be "glCreateShaderObjectARB", but it relies on the fact that glXGetProcAddress will return NULL when called with "glCreateShaderObject" so that it can append "ARB" and try again.
Mesa for some reason decides to return a non-null pointer for "glCreateShaderObject" even though it does not have this function, and segfaults.
As David said, the Mesa team say not to rely on returned pointers being NULL as an indication that the driver supports the OpenGL extension so I am not sure if this is a Mesa bug or a Mojoshader one.
Created attachment 3032 [details] strace Debian Lenny strace Debian Lenny
Created attachment 3033 [details] strace Debian Lenny strace Debian Lenny
Created attachment 3041 [details] ltrace I think it is more because of this: open("resources/Shaders/F8F5D6A5.bin", O_RDONLY) = 11 fstat64(11, {st_mode=S_IFREG|0644, st_size=320, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x9e0d0000 read(11, "\0\2\377\377\376\3778\0CTAB\34\0\0\0\253\0\0\0\0\2\377\377\3\0\0\0\34\0\0\0\0"..., 4096) = 320 read(11, ""..., 4096) = 0 close(11) = 0 munmap(0x9e0d0000, 4096) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- Also, attached ltrace
Created attachment 3044 [details] non-working strace strace on a system in which SMB segfaults.
Created attachment 3045 [details] working strace strace on a system in which SMB runs fine.