After many hours of testing "World of Warcraft" in OpenGL mode, I have hit upon two problems. I don't know if they are related. I have also configured Wine to ignore the GL_ARB_vertex_program extension. The first problem is that under certain circumstances, the text starts rendering incorrectly, and continues to do so until the game is restarted. (See attachment.) The effect looks very similar to that seen in bug #8027 before the relevant fix, which is why I am raising a bug here: https://bugs.freedesktop.org/attachment.cgi?id=6721 What seems to trigger it is entering a building, tunnel or other enclosed environment, although there are exceptions. There is a Wine patch for a problem that sounds *similar* to this, but applying the patch has not made any difference. This problem does not happen in Direct3D mode. It also goes away in OpenGL mode if I configure Wine to ignore the GL_ARB_vertex_buffer_object extension as well. The second problem was a single, spontaneous GPU lockup in OpenGL mode. Both GL_ARB_vertex_program and GL_ARB_vertex_buffer_object were being ignored at the time.
Created attachment 6904 [details] Warcraft, badly rendered text. Observe that all the text is being "pulled" to the bottom left-hand corner of the screen. Also notice that the map disc in the top right-hand corner of the screen is completely white/blank; this seems to be important for triggering the issue. Could something be sending the r200 driver bad data?
I have dug a little deeper into this issue, and it looks like the first problem mentioned in the bug description is actually two distinct problems: the "stretched text" problem and the "blank minimap" problem. These two problems both manifest under exactly the same conditions, namely entering a building. However, the "stretched text" problem can be worked around by disabling the GL_ARB_vertex_buffer_object extension. I have not yet been able to work around the "blank minimap" problem. I have also noticed that the "blank minimap" problem goes away when you leave the building in question, whereas the "stretched text" problem does not. The only way to resolve the "stretched text" problem once it appears is to restart Warcraft.
Latest report: I haven't had a GPU lockup for several days now, which may (but may not) be related to the r200 fixes that went into CVS this week. I still haven't been able to work around the "blank minimap" problem in buildings, but have discovered that I can avoid the "stretched text" problem when GL_ARB_vertex_buffer_object is enabled by closing the minimap before entering a building and then reopening it again when I leave. So I am concluding that the "stretched text" problem is caused by trying to draw an indoor minimap using GL_ARB_vertex_buffer_object. I was unable to get any more information about this; compiling r200_dri.so with -DDEBUG didn't show me anything unusual. Apart from the "blank minimap" and "stretched text" problems, and a rare GPU lockup, I would say that Warcraft is very playable in OpenGL mode. The only other issue is anything that might increase the FPS.
Created attachment 7085 [details] valgrind 3.1.0 output from bufferobj program I'm not sure how capable valgrind 3.1.0 is of finding errors in Mesa memory, but the r200 DRI seems to implement vertex buffer objects in software and so I thought it worth a look.
Created attachment 7086 [details] valgrind 3.1.0 output from arbvpwarpmesh Uninitialised values and invalid writes(?).
Created attachment 7087 [details] valgrind 3.1.0 output from arbvptest3 Uninitialised values and invalid writes(?).
Created attachment 7088 [details] valgrind 3.1.0 output from fogcoord Uninitialised values and different invalid(?) writes.
Created attachment 7089 [details] valgrind 3.1.0 output from manytex Uninitialised values and invalid(?) writes.
Created attachment 7090 [details] valgrind 3.1.0 output from yuvrect Uninitialised values and invalid(?) memcpy() and writes.
(In reply to comment #5) > Created an attachment (id=7086) [edit] > valgrind 3.1.0 output from arbvpwarpmesh > > Uninitialised values and invalid writes(?). I'm not an expert for valgrind. Just some quick thoughts: ==17068== Conditional jump or move depends on uninitialised value(s) ==17068== at 0x4147992: r200Clear (r200_ioctl.c:698) ==17068== Conditional jump or move depends on uninitialised value(s) ==17068== at 0x4146ECA: r200WaitForFrameCompletion (r200_ioctl.c:391) These two don't look unitialized to me - I think valgrind can't know that these values (in the sarea) are indeed written by drm, and thus assumes they aren't initialized. Lots of those: ==17068== Invalid write of size 4 ==17068== at 0x4167F6C: emit_vector (r200_maos_arrays.c:287) Not sure. I guess it's the float/int casts causing trouble here? Those in the swtcl path look fairly similar. ==17068== Invalid write of size 4 ==17068== at 0x415F72A: r200_render_quad_strip_verts (t_dd_triemit.h:80) IIRC gcc will actually report warnings when compiled with strict aliasing at around these places. These two are intersting: ==17068== Syscall param write(buf) points to uninitialised byte(s) ==17068== at 0x41485F13: __write_nocancel (in /lib/libc-2.4.so) ==17068== by 0x4157567E: _X11TransWrite (in /usr/lib/libX11.so.6.2.0) ==17068== Syscall param ioctl(generic) points to uninitialised byte(s) ==17068== at 0x4148D3B9: ioctl (in /lib/libc-2.4.so) ==17068== by 0x4141279: do_wait (vblank.c:243) ==17068== by 0x4141350: driWaitForVBlank (vblank.c:311) ==17068== by 0x4148618: r200CopyBuffer (r200_ioctl.c:453) ==17068== by 0x4145775: r200SwapBuffers (r200_context.c:653) ==17068== by 0x414148E: driSwapBuffers (dri_util.c:472) ==17068== by 0x4277AEDD: glXSwapBuffers (in /usr/lib/libGL.so.1.2) ==17068== by 0x410F453D: glutSwapBuffers (in /usr/lib/libglut.so.3.8.0) ==17068== by 0x80494F4: Display (arbvpwarpmesh.c:88) ==17068== by 0x410FCB85: (within /usr/lib/libglut.so.3.8.0) ==17068== by 0x41100161: fgEnumWindows (in /usr/lib/libglut.so.3.8.0) ==17068== by 0x410FD43A: glutMainLoopEvent (in /usr/lib/libglut.so.3.8.0) ==17068== Address 0xBEB412E4 is on thread 1's stack ==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints ==17068== This could cause spurious value errors to appear. ==17068== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints ==17068== This could cause spurious value errors to appear. ==17068== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints ==17068== This could cause spurious value errors to appear. ==17068== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. I've no idea what the problem here really is (yeah yeah I know I should read se values (in the sarea) are indeed written by drm, and thus assumes they aren't initialized. Lots of those: ==17068== Invalid write of size 4 ==17068== at 0x4167F6C: emit_vector (r200_maos_arrays.c:287) Not sure. I guess it's the float/int casts causing trouble here? Those in the swtcl path look fairly similar. ==17068== Invalid write of size 4 ==17068== at 0x415F72A: r200_render_quad_strip_verts (t_dd_triemit.h:80) IIRC gcc will actually report warnings when compiled with strict aliasing at around these places. These two are intersting: ==17068== Syscall param write(buf) points to uninitialised byte(s) ==17068== at 0x41485F13: __write_nocancel (in /lib/libc-2.4.so) ==17068== by 0x4157567E: _X11TransWrite (in /usr/lib/libX11.so.6.2.0) ==17068== Syscall param ioctl(generic) points to uninitialised byte(s) ==17068== at 0x4148D3B9: ioctl (in /lib/libc-2.4.so) ==17068== by 0x4141279: do_wait (vblank.c:243) ==17068== by 0x4141350: driWaitForVBlank (vblank.c:311) ==17068== by 0x4148618: r200CopyBuffer (r200_ioctl.c:453) ==17068== by 0x4145775: r200SwapBuffers (r200_context.c:653) ==17068== by 0x414148E: driSwapBuffers (dri_util.c:472) ==17068== by 0x4277AEDD: glXSwapBuffers (in /usr/lib/libGL.so.1.2) ==17068== by 0x410F453D: glutSwapBuffers (in /usr/lib/libglut.so.3.8.0) ==17068== by 0x80494F4: Display (arbvpwarpmesh.c:88) ==17068== by 0x410FCB85: (within /usr/lib/libglut.so.3.8.0) ==17068== by 0x41100161: fgEnumWindows (in /usr/lib/libglut.so.3.8.0) ==17068== by 0x410FD43A: glutMainLoopEvent (in /usr/lib/libglut.so.3.8.0) ==17068== Address 0xBEB412E4 is on thread 1's stack ==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints ==17068== This could cause spurious value errors to appear. ==17068== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints ==17068== This could cause spurious value errors to appear. ==17068== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints ==17068== This could cause spurious value errors to appear. ==17068== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. I've no idea what the problem here really is (yeah yeah I know I should read se values (in the sarea) are indeed written by drm, and thus assumes they aren't initialized. Lots of those: ==17068== Invalid write of size 4 ==17068== at 0x4167F6C: emit_vector (r200_maos_arrays.c:287) Not sure. I guess it's the float/int casts causing trouble here? Those in the swtcl path look fairly similar. ==17068== Invalid write of size 4 ==17068== at 0x415F72A: r200_render_quad_strip_verts (t_dd_triemit.h:80) IIRC gcc will actually report warnings when compiled with strict aliasing at around these places. These two are intersting: ==17068== Syscall param write(buf) points to uninitialised byte(s) ==17068== at 0x41485F13: __write_nocancel (in /lib/libc-2.4.so) ==17068== by 0x4157567E: _X11TransWrite (in /usr/lib/libX11.so.6.2.0) ==17068== Syscall param ioctl(generic) points to uninitialised byte(s) ==17068== at 0x4148D3B9: ioctl (in /lib/libc-2.4.so) ==17068== by 0x4141279: do_wait (vblank.c:243) ==17068== by 0x4141350: driWaitForVBlank (vblank.c:311) ==17068== by 0x4148618: r200CopyBuffer (r200_ioctl.c:453) ==17068== by 0x4145775: r200SwapBuffers (r200_context.c:653) ==17068== by 0x414148E: driSwapBuffers (dri_util.c:472) ==17068== by 0x4277AEDD: glXSwapBuffers (in /usr/lib/libGL.so.1.2) ==17068== by 0x410F453D: glutSwapBuffers (in /usr/lib/libglut.so.3.8.0) ==17068== by 0x80494F4: Display (arbvpwarpmesh.c:88) ==17068== by 0x410FCB85: (within /usr/lib/libglut.so.3.8.0) ==17068== by 0x41100161: fgEnumWindows (in /usr/lib/libglut.so.3.8.0) ==17068== by 0x410FD43A: glutMainLoopEvent (in /usr/lib/libglut.so.3.8.0) ==17068== Address 0xBEB412E4 is on thread 1's stack ==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints ==17068== This could cause spurious value errors to appear. ==17068== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints ==17068== This could cause spurious value errors to appear. ==17068== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints ==17068== This could cause spurious value errors to appear. ==17068== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. I've no idea what the problem here really is (yeah yeah I know I should read README_MISSING_SYSCALL_OR_IOCTL), the first one of these is somewhere buried in libX11, maybe that's part of Xorg's ioctl-wrapper-for-everything design. As for ARB_vbo, you're right they are not implemented in the driver. Any bugs you see when using them are likely either a bug in mesa core, an application bug, or exhibiting a problem which does not exist without them because the app would do something different when not using it (i.e. instead of just doing basically the same but with standard vertex arrays, it might do something completely different). Last possibility would be the r200 vtxfmt code, if it's no longer buggy if you use tcl_mode=1 then that's the case.
Sorry for the unreadable copy & paste mess caused by the stupid small comment box (and it's not possible to edit afterwards). Corrected version follows. (In reply to comment #5) > Created an attachment (id=7086) [edit] > valgrind 3.1.0 output from arbvpwarpmesh > > Uninitialised values and invalid writes(?). I'm not an expert for valgrind. Just some quick thoughts: ==17068== Conditional jump or move depends on uninitialised value(s) ==17068== at 0x4147992: r200Clear (r200_ioctl.c:698) ==17068== Conditional jump or move depends on uninitialised value(s) ==17068== at 0x4146ECA: r200WaitForFrameCompletion (r200_ioctl.c:391) These two don't look unitialized to me - I think valgrind can't know that these values (in the sarea) are indeed written by drm, and thus assumes they aren't initialized. Lots of those: ==17068== Invalid write of size 4 ==17068== at 0x4167F6C: emit_vector (r200_maos_arrays.c:287) Not sure. I guess it's the float/int casts causing trouble here? Those in the swtcl path look fairly similar. ==17068== Invalid write of size 4 ==17068== at 0x415F72A: r200_render_quad_strip_verts (t_dd_triemit.h:80) IIRC gcc will actually report warnings when compiled with strict aliasing at around these places. These two are somewhat interesting: ==17068== Syscall param write(buf) points to uninitialised byte(s) ==17068== at 0x41485F13: __write_nocancel (in /lib/libc-2.4.so) ==17068== by 0x4157567E: _X11TransWrite (in /usr/lib/libX11.so.6.2.0) ==17068== Syscall param ioctl(generic) points to uninitialised byte(s) ==17068== at 0x4148D3B9: ioctl (in /lib/libc-2.4.so) ==17068== by 0x4141279: do_wait (vblank.c:243) ==17068== by 0x4141350: driWaitForVBlank (vblank.c:311) ==17068== by 0x4148618: r200CopyBuffer (r200_ioctl.c:453) ==17068== by 0x4145775: r200SwapBuffers (r200_context.c:653) ==17068== by 0x414148E: driSwapBuffers (dri_util.c:472) ==17068== by 0x4277AEDD: glXSwapBuffers (in /usr/lib/libGL.so.1.2) ==17068== by 0x410F453D: glutSwapBuffers (in /usr/lib/libglut.so.3.8.0) ==17068== by 0x80494F4: Display (arbvpwarpmesh.c:88) ==17068== by 0x410FCB85: (within /usr/lib/libglut.so.3.8.0) ==17068== by 0x41100161: fgEnumWindows (in /usr/lib/libglut.so.3.8.0) ==17068== by 0x410FD43A: glutMainLoopEvent (in /usr/lib/libglut.so.3.8.0) ==17068== Address 0xBEB412E4 is on thread 1's stack ==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints ==17068== This could cause spurious value errors to appear. ==17068== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints ==17068== This could cause spurious value errors to appear. ==17068== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints ==17068== This could cause spurious value errors to appear. ==17068== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. I've no idea what the problem here really is (yeah yeah I know I should read README_MISSING_SYSCALL_OR_IOCTL), the first one of these is somewhere buried in libX11, maybe that's part of Xorg's ioctl-wrapper-for-everything design. As for ARB_vbo, you're right they are not implemented in the driver. Any bugs you see when using them are likely either a bug in mesa core, an application bug, or exhibiting a problem which does not exist without them because the app would do something different when not using it (i.e. instead of just doing basically the same but with standard vertex arrays, it might do something completely different). Last possibility would be the r200 vtxfmt code, if it's no longer buggy if you use tcl_mode=1 then that's the case.
(In reply to comment #11) > Lots of those: > ==17068== Invalid write of size 4 > ==17068== at 0x4167F6C: emit_vector (r200_maos_arrays.c:287) > Not sure. I guess it's the float/int casts causing trouble here? > > Those in the swtcl path look fairly similar. > ==17068== Invalid write of size 4 > ==17068== at 0x415F72A: r200_render_quad_strip_verts (t_dd_triemit.h:80) > IIRC gcc will actually report warnings when compiled with strict aliasing at > around these places. That's probably not a related problem, however, I was wrong. Those writes are invalid because valgrind thinks we're writing past allocated memory. This is however not the case, again valgrind doesn't know that this memory (those are writes to the indirect buffers) is allocated elsewhere. Well, that's what I think happens, at least.
(In reply to comment #11) > Lots of those: > ==17068== Invalid write of size 4 > ==17068== at 0x4167F6C: emit_vector (r200_maos_arrays.c:287) > Not sure. I guess it's the float/int casts causing trouble here? What float/int casts? out is an int* and data is a char*, so where's the float? This also looked interesting: ==17123== Invalid write of size 1 ==17123== at 0x40069A6: memcpy (mac_replace_strmem.c:394) ==17123== by 0x4156245: r200UploadTexImages (string3.h:51) ==17123== by 0x41580E9: r200UpdateTextureUnit (r200_texstate.c:1546) ==17123== by 0x41585FF: r200UpdateTextureState (r200_texstate.c:1668) ==17123== by 0x414C5E3: r200ValidateState (r200_state.c:2372) ==17123== by 0x4145560: r200MakeCurrent (r200_context.c:718) ==17123== by 0x414225F: driBindContext (dri_util.c:343) ==17123== by 0x4277CABB: (within /usr/lib/libGL.so.1.2) ==17123== by 0x4277ECAE: glXMakeContextCurrent (in /usr/lib/libGL.so.1.2) ==17123== by 0x4277EF42: glXMakeCurrent (in /usr/lib/libGL.so.1.2) ==17123== by 0x41101B5B: fgSetWindow (in /usr/lib/libglut.so.3.8.0) ==17123== by 0x410FD2E6: glutMainLoopEvent (in /usr/lib/libglut.so.3.8.0) ==17123== Address 0xB7D16183 is not stack'd, malloc'd or (recently) free'd And with regards to the vbo code: ... > Last possibility would be the r200 vtxfmt code, if it's > no longer buggy if you use tcl_mode=1 then that's the case. I switched to tcl_mode=1 by default a while ago because I thought it might be faster (hardware vs software), and the feature is still buggy when ARB_vbo is enabled. This is basically why I tried using valgrind - to see if anything showed up in the software vbo code. Incidentally, I saw that the r300 implements vbos in hardware. Is this an extra feature of the R300 hardware, or could the R200 hardware do this too?
(In reply to comment #13) > (In reply to comment #11) > > Lots of those: > > ==17068== Invalid write of size 4 > > ==17068== at 0x4167F6C: emit_vector (r200_maos_arrays.c:287) > > Not sure. I guess it's the float/int casts causing trouble here? > What float/int casts? out is an int* and data is a char*, so where's the float? Yeah, no float there. As I already mentioned, the problem (which actually is only a problem with valgrind) seems to be entirely different anyway. > This also looked interesting: > ==17123== Invalid write of size 1 > ==17123== at 0x40069A6: memcpy (mac_replace_strmem.c:394) > ==17123== by 0x4156245: r200UploadTexImages (string3.h:51) > ==17123== by 0x41580E9: r200UpdateTextureUnit (r200_texstate.c:1546) Yes, somewhat interesting. Unfortunately the output is a bit useless, what's up with that string3.h file? No idea on which line in r200UploadTexImages function this happens. > And with regards to the vbo code: > ... > > Last possibility would be the r200 vtxfmt code, if it's > > no longer buggy if you use tcl_mode=1 then that's the case. > > I switched to tcl_mode=1 by default a while ago because I thought it might be > faster (hardware vs software), and the feature is still buggy when ARB_vbo is > enabled. This is basically why I tried using valgrind - to see if anything > showed up in the software vbo code. Yes, with modern games, tcl_mode=1 should never be slower, as all modern apps use vertex arrays, which cause a straight fallback out of vtxfmt code all the time (and it might thus save some cpu time for not doing some additional work - it's highly unlikely to make really a measurable difference though). > Incidentally, I saw that the r300 implements vbos in hardware. Is this an extra > feature of the R300 hardware, or could the R200 hardware do this too? No, r200 (and r100 too) can easily do that, with basically the same code as r300 uses for that. It's on my TODO list...
(In reply to comment #14) > > > Incidentally, I saw that the r300 implements vbos in hardware. Is this an extra > > feature of the R300 hardware, or could the R200 hardware do this too? > No, r200 (and r100 too) can easily do that, with basically the same code as r300 > uses for that. It's on my TODO list... FWIW, I think it might be better to move all these drivers to the upcoming common memory manager instead of putting more effort into the r300 hack.
(In reply to comment #15) > > > Incidentally, I saw that the r300 implements vbos in hardware. Is this an extra > > > feature of the R300 hardware, or could the R200 hardware do this too? > > No, r200 (and r100 too) can easily do that, with basically the same code as r300 > > uses for that. It's on my TODO list... > > FWIW, I think it might be better to move all these drivers to the upcoming > common memory manager instead of putting more effort into the r300 hack. For sure. One of the reasons I didn't work on it, I'm waiting for these drivers to magically migrate to the new memory manager ;-).
(In reply to comment #14) > > This also looked interesting: > > ==17123== Invalid write of size 1 > > ==17123== at 0x40069A6: memcpy (mac_replace_strmem.c:394) > > ==17123== by 0x4156245: r200UploadTexImages (string3.h:51) > > ==17123== by 0x41580E9: r200UpdateTextureUnit (r200_texstate.c:1546) > Yes, somewhat interesting. Unfortunately the output is a bit useless, what's > up with that string3.h file? No idea on which line in r200UploadTexImages > function this happens. I removed the "static" qualifiers from a few functions, and now the valgrind output looks like this: ==28760== Invalid write of size 1 ==28760== at 0x40069A6: memcpy (mac_replace_strmem.c:394) ==28760== by 0x415582E: r200UploadRectSubImage (string3.h:51) ==28760== by 0x4155F13: uploadSubImage (r200_texmem.c:322) ==28760== by 0x41564D0: r200UploadTexImages (r200_texmem.c:516) ==28760== by 0x4158689: r200UpdateTextureUnit (r200_texstate.c:1671) ==28760== by 0x4158B9F: r200UpdateTextureState (r200_texstate.c:1793) ==28760== by 0x414C6C3: r200ValidateState (r200_state.c:2372) ==28760== by 0x4145640: r200MakeCurrent (r200_context.c:718) ==28760== by 0x414233F: driBindContext (dri_util.c:343) ==28760== by 0x4277CABB: (within /usr/lib/libGL.so.1.2) ==28760== by 0x4277ECAE: glXMakeContextCurrent (in /usr/lib/libGL.so.1.2) ==28760== by 0x4277EF42: glXMakeCurrent (in /usr/lib/libGL.so.1.2) ==28760== Address 0xB7EEC183 is not stack'd, malloc'd or (recently) free'd ==28760== ==28760== Invalid write of size 1 ==28760== at 0x40069AC: memcpy (mac_replace_strmem.c:394) ==28760== by 0x415582E: r200UploadRectSubImage (string3.h:51) ==28760== by 0x4155F13: uploadSubImage (r200_texmem.c:322) ==28760== by 0x41564D0: r200UploadTexImages (r200_texmem.c:516) ==28760== by 0x4158689: r200UpdateTextureUnit (r200_texstate.c:1671) ==28760== by 0x4158B9F: r200UpdateTextureState (r200_texstate.c:1793) ==28760== by 0x414C6C3: r200ValidateState (r200_state.c:2372) ==28760== by 0x4145640: r200MakeCurrent (r200_context.c:718) ==28760== by 0x414233F: driBindContext (dri_util.c:343) ==28760== by 0x4277CABB: (within /usr/lib/libGL.so.1.2) ==28760== by 0x4277ECAE: glXMakeContextCurrent (in /usr/lib/libGL.so.1.2) ==28760== by 0x4277EF42: glXMakeCurrent (in /usr/lib/libGL.so.1.2) ==28760== Address 0xB7EEC182 is not stack'd, malloc'd or (recently) free'd ==28760== ==28760== Invalid write of size 1 ==28760== at 0x40069B3: memcpy (mac_replace_strmem.c:394) ==28760== by 0x415582E: r200UploadRectSubImage (string3.h:51) ==28760== by 0x4155F13: uploadSubImage (r200_texmem.c:322) ==28760== by 0x41564D0: r200UploadTexImages (r200_texmem.c:516) ==28760== by 0x4158689: r200UpdateTextureUnit (r200_texstate.c:1671) ==28760== by 0x4158B9F: r200UpdateTextureState (r200_texstate.c:1793) ==28760== by 0x414C6C3: r200ValidateState (r200_state.c:2372) ==28760== by 0x4145640: r200MakeCurrent (r200_context.c:718) ==28760== by 0x414233F: driBindContext (dri_util.c:343) ==28760== by 0x4277CABB: (within /usr/lib/libGL.so.1.2) ==28760== by 0x4277ECAE: glXMakeContextCurrent (in /usr/lib/libGL.so.1.2) ==28760== by 0x4277EF42: glXMakeCurrent (in /usr/lib/libGL.so.1.2) ==28760== Address 0xB7EEC181 is not stack'd, malloc'd or (recently) free'd ==28760== ==28760== Invalid write of size 1 ==28760== at 0x40069BD: memcpy (mac_replace_strmem.c:394) ==28760== by 0x415582E: r200UploadRectSubImage (string3.h:51) ==28760== by 0x4155F13: uploadSubImage (r200_texmem.c:322) ==28760== by 0x41564D0: r200UploadTexImages (r200_texmem.c:516) ==28760== by 0x4158689: r200UpdateTextureUnit (r200_texstate.c:1671) ==28760== by 0x4158B9F: r200UpdateTextureState (r200_texstate.c:1793) ==28760== by 0x414C6C3: r200ValidateState (r200_state.c:2372) ==28760== by 0x4145640: r200MakeCurrent (r200_context.c:718) ==28760== by 0x414233F: driBindContext (dri_util.c:343) ==28760== by 0x4277CABB: (within /usr/lib/libGL.so.1.2) ==28760== by 0x4277ECAE: glXMakeContextCurrent (in /usr/lib/libGL.so.1.2) ==28760== by 0x4277EF42: glXMakeCurrent (in /usr/lib/libGL.so.1.2) ==28760== Address 0xB7EEC180 is not stack'd, malloc'd or (recently) free'd ==28760== string3.h is actually /usr/include/bits/string3.h, which defines memcpy() thus: #define memcpy(dest, src, len) \ ((__bos0 (dest) != (size_t) -1) \ ? __builtin___memcpy_chk (dest, src, len, __bos0 (dest)) \ : __memcpy_ichk (dest, src, len)) static __always_inline void * __NTH (__memcpy_ichk (void *__restrict __dest, __const void *__restrict __src, size_t __len)) { return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest)); }
(In reply to comment #17) > I removed the "static" qualifiers from a few functions, and now the valgrind > output looks like this: > > ==28760== Invalid write of size 1 > ==28760== at 0x40069A6: memcpy (mac_replace_strmem.c:394) > ==28760== by 0x415582E: r200UploadRectSubImage (string3.h:51) > ==28760== by 0x4155F13: uploadSubImage (r200_texmem.c:322) > ==28760== by 0x41564D0: r200UploadTexImages (r200_texmem.c:516) Ah didn't realize that's for rectangular texture upload before. So this is again a write to the (not-allocated-here) indirect buffer area, thus probably not a bug.
After a week of silence, other Wine users are now starting to report these same "stretched text" and "blank minimap" bugs with the fglrx/NVIDIA drivers. I am therefore assuming that these bugs are nothing to do with MESA or DRI after all.
Mass version move, cvs -> git
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.