Maybe I am seeing the same thing here. But in addition, my Xserver crashes and I am put back to the GDM login window :/

Fedora 16 64-bit with 32-bit compat libs. 

OpenGL renderer string: Mesa DRI Intel(R) 965GM 
OpenGL version string: 2.1 Mesa 7.11.2

Created attachment 3039 [details]
strace of crash

Attached strace

Created attachment 3040 [details]
ltrace

Attached ltrace.
It sems to be related with shaders/fullscreeneffects

gdb backtrace doesn't help...

(gdb) bt
#0  0x00000584 in ?? ()
#1  0xbffff604 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


Is there anything else I can do ?

I see the same thing, but with a somewhat better backtrace:

Core was generated by `bin/Shank'.
Program terminated with signal 11, Segmentation fault.
#0  0x00001289 in ?? ()
(gdb) bt
#0  0x00001289 in ?? ()
#1  0x0845fed8 in impl_GLSL_CompileShader ()
#2  0x08461ae0 in MOJOSHADER_glCompileShader ()
#3  0x081eb785 in Rendering::Effect::OnCreateDevice() ()
#4  0x081ed045 in KGHelper::PVWEffect::OnCreateDevice() ()
#5  0x081eeaa9 in KGraphics::DeviceCreateCommon() ()
#6  0x081d8c2d in KGraphics::OnCreateDevice() ()
#7  0x081e029b in KGraphics::CreateDevice() ()
#8  0x081e058a in KGraphics::Initialize(void*) ()
#9  0x083bd14b in AppInterface::BootInitialize() ()
#10 0x083c15d9 in main ()

(The just-above-NULLs are interesting. Calling a function on a NULL object would lead to a normal-looking IP and nearly-NULL parameter. What could lead to a call just above NULL like this? The answer is tickling at the edge of my memory but it's been ten years since I saw this symptom last and I just can't remember...)

(In reply to comment #5)
> I see the same thing, but with a somewhat better backtrace:
> 
> Core was generated by `bin/Shank'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x00001289 in ?? ()
> (gdb) bt
> #0  0x00001289 in ?? ()
> #1  0x0845fed8 in impl_GLSL_CompileShader ()
> #2  0x08461ae0 in MOJOSHADER_glCompileShader ()
> #3  0x081eb785 in Rendering::Effect::OnCreateDevice() ()
> #4  0x081ed045 in KGHelper::PVWEffect::OnCreateDevice() ()
> #5  0x081eeaa9 in KGraphics::DeviceCreateCommon() ()
> #6  0x081d8c2d in KGraphics::OnCreateDevice() ()
> #7  0x081e029b in KGraphics::CreateDevice() ()
> #8  0x081e058a in KGraphics::Initialize(void*) ()
> #9  0x083bd14b in AppInterface::BootInitialize() ()
> #10 0x083c15d9 in main ()
> 
> (The just-above-NULLs are interesting. Calling a function on a NULL object
> would lead to a normal-looking IP and nearly-NULL parameter. What could lead to
> a call just above NULL like this? The answer is tickling at the edge of my
> memory but it's been ten years since I saw this symptom last and I just can't
> remember...)

At least this crash, and possibly all others mentioned here, are caused by the same problem as bug 5315.

Interesting. That bug is reported to affect Super Meat Boy as well, though that works for me (though that game's focus on gamepads remains fantastically irritating, I have to translate in my head to keybindings all the time: maybe there are USB gamepads out there, but I don't have one).

I wonder if Super Meat Boy gets it right sometimes and wrong sometimes, or simply decides to eschew shaders on my machine entirely for some reason? (I'm using Gallium, Mesa 7.11.2 with an ATI Radeon 4870.)

Yes, looks to be the same crash as SMB.  

The Mesa team says that the application is using an extension that isn't supported on some hardware/drivers and that's causing the crash.  They said that even if Mesa returns a non-null pointer, it doesn't mean that the extension is supported by the hardware, and the application needs to check to make sure the extension is supported before using the pointer (which may be non-null even when unsupported). 

But the application (both SMB and Shank) is using the pointer if it's non-null assuming that it is a supported OpenGL extension.

The funny thing is that when mesa is compiled with x86 assembly optimizaitons, it returns non-null if it's not supported.. But if it's NOT compiled with x86 assembly optimizations on the exact same hardware, it returns null if it's not supported..  Regardless, the MESA team says that the returned value should never be used to determine hardware support for the OpenGL extension GL_ARB_transform_feedback2 and it needs to be checked specifically by the application through GL_EXTENSIONS before using pointers like that.

Similar bug

*** This bug has been marked as a duplicate of bug 5315 ***

Just updating this bug to be a duplicate of a different bug. Please see the Shank hotfix in Bug #5336, and let me know if it fixes this issue.

Thanks!

--ryan.

*** This bug has been marked as a duplicate of bug 5336 ***