With the current git master and any Gallium driver, trying to play any game in Mupen64Plus (with its default video plugin) results in a segfault almost immediately when the driver tries to draw or validate VBOs. I've confirmed this on softpipe, llvmpipe, and nv50. I've bisected the regression to this commit: commit 12fa91b6753dccbd3aa12c570d1f1e55c7dc0582 Author: Thomas Hellstrom <thellstrom@vmware.com> Date: Mon Mar 7 11:24:43 2011 +0100 st/mesa: Fix an incorrect user vertex buffer reference st->user_vb[attr] was always pointing to the same user vb, regardless of the value of attr. Together with reverting the temporary workaround for bug 34378, and a fix in the svga driver, this fixes googleearth on svga. Reverting only the second part of that commit fixes the issue in master, although that looks like more of a workaround than a proper fix.
IIRC, the second part of that commit was only to enable the redefine_user_buffer() calls, which we've ended up not really using anyway, so I'm fine with reverting that. However, I think Marek is the one who knows this code the best and knows what to do and what not. Marek, any suggestions. Meanwhile, Bryan, can you add a backtrace of the segfault? Thanks, Thomas
The backtrace is different depending on the driver being used, since the segfault is inside of the actual driver. For the nv50 driver, this is the backtrace from gdb: Program received signal SIGSEGV, Segmentation fault. nv50_vertex_arrays_validate (nv50=<value optimized out>) at nv50_vbo.c:338 338 size = vb->buffer->width0; (gdb) bt #0 nv50_vertex_arrays_validate (nv50=<value optimized out>) at nv50_vbo.c:338 #1 0xb493c0d4 in nv50_state_validate (nv50=0x813ec20) at nv50_state_validate.c:337 #2 0xb492637d in nv50_draw_vbo (pipe=0x813ec20, info=0xbfffeed8) at nv50_vbo.c:650 #3 0xb49fa9ac in st_draw_vbo (ctx=0x81e7130, arrays=0x822be64, prims=0xbfffef6c, nr_prims=1, ib=0xbfffef80, index_bounds_valid=0 '\000', min_index=0, max_index=17) at state_tracker/st_draw.c:763 #4 0xb4ab0c01 in vbo_validated_drawrangeelements (ctx=0x81e7130, mode=<value optimized out>, index_bounds_valid=<value optimized out>, start=4294967295, end=4294967295, count=18, type=5125, indices=0xb5b22c60, basevertex=0, numInstances=1) at vbo/vbo_exec_array.c:846 #5 0xb4ab0e3e in vbo_exec_DrawElements (mode=4, count=18, type=5125, indices=0xb5b22c60) at vbo/vbo_exec_array.c:1005 #6 0xb5a26c02 in ?? () from /usr/lib/mupen64plus/mupen64plus-video-rice.so #7 0xb5a2a3c0 in ?? () from /usr/lib/mupen64plus/mupen64plus-video-rice.so #8 0xb5a44199 in ?? () from /usr/lib/mupen64plus/mupen64plus-video-rice.so #9 0xb5ab9676 in ProcessDList () from /usr/lib/mupen64plus/mupen64plus-video-rice.so #10 0xb5817806 in DoRspCycles () from /usr/lib/mupen64plus/mupen64plus-rsp-hle.so #11 0x80016940 in ?? () #12 0x09417f64 in ?? ()
Please make and attach an apitrace file. More info is here: https://bugs.freedesktop.org/show_bug.cgi?id=36745#c15
Created attachment 48902 [details] apitrace for Mupen64Plus Well, this is an interesting twist. With apitrace, the segfault doesn't happen and the game goes on normally. Without it, with everything else the same, the segfault happens. Anyway, here's the trace. I closed it a second or so after the place where it usually segfaults.
r600g doesn't crash, but misrenders. That might be some other problem though. (I tried Mupen64, not apitrace). softpipe and llvmpipe do crash. swrast renders everything correctly. It's obviously a bug in Draw and nv50. I can't obtain a backtrace from Mupen64. Reassigning to mesa-dev again.
Created attachment 54965 [details] gdb session I'm also getting this crash. I've attached a log from gdb showing the immediate cause of the crash, let me know if there's any more information I can provide.
I seem to be getting this issue as well, mupen64plus crashes on my machine as soon as I start a game. Mupen64Plus Console User-Interface Version 1.99.4 UI-console: attached to core library 'Mupen64Plus Core' version 1.99.4 I've tried building from source (hg) and it doesn't crash there but it hangs. It used to work fine with previous versions. I'm using nouveau, Linux 3.2.2, Arch Linux x86-64.
BTW I use nouveau, and my card is: GeForce 9500 GT
Created attachment 56498 [details] mupen64plus gdb backtrace I've managed to get a backtrace. See the file attached.
I'm actually not sure if this is the same issue the reporter was experiencing. But setting ColorQuality to 1 in [Video-Rice] section worked as a workaround for me. Like this: [Video-Rice] # Color bit depth for rendering window (0=32 bits, 1=16 bits) ColorQuality = 1 I set that in this file: /home/diego/.config/mupen64plus Then mupen64plus doesn't crash/segfault. This is with nouveau driver, Arch Linux x86-64, Linux 3.2.2, mupen64plus 1.99.4.
It has been a very long time since this was reported. Can you confirm if this issue has been fixed in recent Gallium drivers?
No reply and no additional reports since 2012 so assuming fixed and closing.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.