mupen64plus crashes with any type of video output

[GoogleCodeExporter]

Describe your system:
 - Linux distribution: Archlinux 64
 - Machine type: 64-bit
 - Mupen64Plus version: v1.5 r1404 (from svn)
 - Plugins used: Any video plugin, jttl's, blight's, and hacktarux.

Describe the problem:
mupen64plus crashes with any video output.
When I disable the video output plugin, the rom runs fine (i can hear the
music) and it doesn't crash.

Please provide any additional information below.
valgrind output (built the trunk with debug symbols) attached.

Original issue reported on code.google.com by tomd...@gmail.com on 14 Sep 2009 at 2:47

Attachments:

• output

[GoogleCodeExporter]

I'm using an intel 945gm btw.

Original comment by tomd...@gmail.com on 14 Sep 2009 at 2:53

[GoogleCodeExporter]

What is the current version of the xorg-intel driver installed? Is KMS enabled? 
Which
version of kernel? What X.org version?

You should try 2.8.2 (or current git snapshot for 2.8.2) as there is currently 
a bug
inside <=2.8.1 of the intel i9xx and i8xx driver which will cause mupen64plus to
crash nearly immediately.

Original comment by sven@narfation.org on 21 Sep 2009 at 2:51

[GoogleCodeExporter]

Sry, was mesa and not the intel driver by itself:

There is also a bug inside mesa <= 7.5.1 which will cause mupen64plus nearly
immediately to crash. Please try a new snapshot of mesa. Debian bug can be 
found at
http://bugs.debian.org/545085

Original comment by sven@narfation.org on 21 Sep 2009 at 2:57

[GoogleCodeExporter]

xf86-video-intel 2.8.1-1
kernel 2.6.31 with KMS enabled by default.
xorg-server 1.6.3.901-1
mesa 7.5.1-2

Original comment by tomd...@gmail.com on 23 Sep 2009 at 3:44

[GoogleCodeExporter]

also, I have this package, (Mesa DRI drivers for Intel chipsets)
intel-dri 7.5.1-2

should I just recompile the mesa and xf86-video-intel?

Original comment by tomd...@gmail.com on 23 Sep 2009 at 3:52

[GoogleCodeExporter]

Probably not. This could be a arch specific problem as the actual problem on 
Debian
is slightly different (Front-Buffer glReadPixels and not Shader related). The
problem in debian has be confirmed by debian and upstream, so maybe you can try 
to
create a small program which creates a shader to see if it still happens and if 
this
is the case then post it to upstream. Can you also create a valgrind log with
another plugin (rice/glide64) as I would think that this one will be like the 
one
the debian bug describes - which just needs mesa 7.5.2 or a arch maintainer 
which
backports patch 04081a164ca6160404d87dccbfc641bfd46428e0,
2855ee82c6d74066e8d9e44b17b2ce3b5782110e, 
cf820a045f0626718ec147ebb26e31f82ec0b4fb
and b2cba25f9eecf2063c3b98d66ade59cd9e50990e from mesa git.

I will test z64 on my eeepc to check if I could the z64 specific problem here 
(the
one in your log).

Original comment by sven@narfation.org on 23 Sep 2009 at 4:26

[GoogleCodeExporter]

Could not recreate the problem here. I used the attached small snipped to test 
the
CreateShader-Problem. Please use 

g++ -o shader shader.cpp `sdl-config --cflags` `sdl-config --libs` -lGL -lGLU 
&& ./shader

to compile it. Maybe you can send it to your team if you still have the problem 
and
it doesn't print 

Vertex Shader not supported
Fragment Shader not supported

In that case your card doesnt support GL_ARB_vertex_shader and 
GL_ARB_fragment_shader
and thus not z64 (which is the cause of the segfault in case of z64).

Original comment by sven@narfation.org on 23 Sep 2009 at 6:23

Attachments:

• shader.cpp

[GoogleCodeExporter]

Ok, my eeepc doesn't support both extensions and your intel chip will not 
support
them too. This means that this is real the problem for z64. Please provide the
requested valgrind output to check if it is real the problem mentioned in
http://bugs.debian.org/545085 and probably bug 253.

Only had small glew related problem that my problem on eeepc looked different to
yours. Stepping through debugging revealed that it is the same problem as you 
had
with z64. I added bug 271 for that specific part of your problem.

Original comment by sven@narfation.org on 23 Sep 2009 at 6:45

[GoogleCodeExporter]

muellhierrein: this is the output of running that program.

Vertex Shader not supported
Fragment Shader not supported

Looks like that was the problem and mupen64plus assumes shader support. I'll be 
back
to check the bug reports you posted.

Original comment by tomd...@gmail.com on 24 Sep 2009 at 4:29

[GoogleCodeExporter]

Please don't forget to create valgrind/backtrace of a plugin like rice or 
glide64 as
mupen64plus doesn't assume shader support, but the experimental plugin z64 does.

Original comment by sven@narfation.org on 24 Sep 2009 at 8:48

[GoogleCodeExporter]

Ok, here is the valgrind output using glide64. Looks like I was hit by two 
different
bugs which caused a crash. The full output of running mupen64plus with valgrind 
is
attached.

==11928== Jump to the invalid address stated on the next line
==11928==    at 0x0: ???
==11928==    by 0x17176218: _swrast_read_rgba_span (in
/usr/lib/xorg/modules/dri/libdricore.so)
==11928==    by 0x17174E73: read_rgba_pixels (in 
/usr/lib/xorg/modules/dri/libdricore.so)
==11928==    by 0x1717582F: _swrast_ReadPixels (in
/usr/lib/xorg/modules/dri/libdricore.so)
==11928==    by 0x16DBCAA4: intelReadPixels (in 
/usr/lib/xorg/modules/dri/i915_dri.so)
==11928==    by 0x170D0137: _mesa_ReadPixels (in 
/usr/lib/xorg/modules/dri/libdricore.so)
==11928==    by 0xD97C13D: grLfbLock (main.cpp:2004)
==11928==    by 0xD90FF96: ReadScreen (Main.cpp:1043)
==11928==    by 0x428ABF: emulationThread (main.c:881)
==11928==    by 0x5915056: SDL_RunThread (in /usr/lib/libSDL-1.2.so.0.11.2)
==11928==    by 0x59595C8: RunThread (in /usr/lib/libSDL-1.2.so.0.11.2)
==11928==    by 0x5BA3579: start_thread (in /lib/libpthread-2.10.1.so)
==11928==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

Original comment by tomd...@gmail.com on 24 Sep 2009 at 9:51

Attachments:

• outputglide

[GoogleCodeExporter]

Yes, this is the mesa bug which should be fixed in the upcoming version 7.5.2

Original comment by sven@narfation.org on 24 Sep 2009 at 10:25

[GoogleCodeExporter]

Yup, just recompiled the latest intel dri from git (along with other things 
from git)
and it works with the latest branches. Thanks for helping me!! :D

Original comment by tomd...@gmail.com on 25 Sep 2009 at 4:42

[GoogleCodeExporter]

So, then we need a maintainer to mark this bug as invalid...

Original comment by sven@narfation.org on 25 Sep 2009 at 9:37

[GoogleCodeExporter]

mesa bug, as noted in previous comments.

Original comment by richard...@gmail.com on 28 Sep 2009 at 8:05

• Changed state: Invalid

[GoogleCodeExporter]

Just as note: mesa 7.6 and 7.5.2 is out which fixes that problem ("Assorted bug 
fixes
for i965/i945 drivers")

Original comment by sven@narfation.org on 29 Sep 2009 at 12:38