Grand Prix 4 in Wine 1.1.29 causes page fault with this backtrace: Backtrace: =>0 0x7d74b4b3 intel_validate_framebuffer+0x63() in i915_dri.so (0x0033f0b8) 1 0x7d53d569 _mesa_test_framebuffer_completeness+0x3c9() in libdricore.so (0x0033f118) 2 0x7d545b9c update_framebuffer+0x13c() in libdricore.so (0x0033f148) 3 0x7d545bd7 _mesa_update_framebuffer+0x27() in libdricore.so (0x0033f168) 4 0x7d703ac8 intel_draw_buffer+0x258() in i915_dri.so (0x0033f1c8) 5 0x7d74bd0b intel_render_texture+0x11b() in i915_dri.so (0x0033f238) 6 0x7d53da56 _mesa_set_texture_attachment+0xa6() in libdricore.so (0x0033f278) 7 0x7d53dcbd framebuffer_texture+0x21d() in libdricore.so (0x0033f2c8) 8 0x7d53e040 _mesa_FramebufferTexture2DEXT+0x70() in libdricore.so (0x0033f2f8) 9 0x7eb37ea2 initPixelFormats+0x922() in wined3d (0x0033f388) 10 0x7eab0034 InitAdapters+0x8ef4() in wined3d (0x0033f8d8) 11 0x7eb3ca83 WineDirect3DCreate+0x63() in wined3d (0x0033f918) 12 0x7eb86606 Direct3DCreate8+0x66() in d3d8 (0x0033f948) (I remember playing this game with mesa-7.3 and some older versions of wine, performance was very bad, but at least the game started.) I have i915GM with 2.6.31 kernel, mesa-7.5 branch from git as of today. I've managed to eliminate this page fault with this patch: diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c b/src/mesa/drivers/dri/intel/intel_fbo.c index 30f58b1..4d6cd41 100644 --- a/src/mesa/drivers/dri/intel/intel_fbo.c +++ b/src/mesa/drivers/dri/intel/intel_fbo.c @@ -679,6 +679,8 @@ intel_validate_framebuffer(GLcontext *ctx, struct gl_framebuffer *fb) if (rb == NULL) continue; + if (irb == NULL) + continue; switch (irb->texformat->MesaFormat) { case MESA_FORMAT_ARGB8888: but the game still doesn't start, and wine/mesa gives these messages and another page fault: Mesa: Mesa 7.5.2-devel DEBUG build Sep 20 2009 21:19:50 Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable Mesa: User error: GL_INVALID_OPERATION in glProgramString(1054: integer value out of range) Mesa: User error: GL_INVALID_OPERATION in glProgramString(bad program)
Mesa 7.6 and later already have the fix you suggested above. I'm cherry-picking it back to the 7.5 branch. I believe the "integer value out of range" error is a normal part of Wine start-up when it probes the limits for address-relative offsets in vertex programs. It can be ignored. Can you provide a stack trace of where the new segfault (not page fault, btw) occurs?
The second segfault seems to be inside wine, I'm not sure whether this is mesa-related, I'll try to debug it. I just wondered if GL_INVALID_OPERATIONs were normal.
A while ago a Mesa user reported a segfault in the Wine code to us, which was caused by what we believe is a bug in the mesa code. glCheckFramebufferStatus() returned 0 instead of one of the error codes in defined in EXT_framebuffer_object. This happened when no framebuffer object was bound(ie, the onscreen framebuffer was used, which should always be complete). glGetError() returns 0 as well, although if glCheckFramebufferStatus returns 0 an error code should be set. Wine has a code like this: ret = glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT); if(ret == GL_FRAMEBUFFER_COMPLETE) { TRACE("Framebuffer OK\n"); } else { ERR("Framebuffer invalid\n"); dump_framebuffer(context->current_fb); } context->current_fb is a Wine structure, and it is NULL when we're not rendering to a FBO. Since the onscreen buffer isn't complete, Wine tries to dump the nonexistant offscreen rendering configuration and thus segfaults.
That's not necessarily related, those users most likely had a broken 32-bit libGL. The bugs in question are http://bugs.winehq.org/show_bug.cgi?id=16516 and http://bugs.winehq.org/show_bug.cgi?id=19417.
(In reply to comment #3) > A while ago a Mesa user reported a segfault in the Wine code to us, which was > caused by what we believe is a bug in the mesa code. glCheckFramebufferStatus() > returned 0 instead of one of the error codes in defined in > EXT_framebuffer_object. This happened when no framebuffer object was bound(ie, > the onscreen framebuffer was used, which should always be complete). > glGetError() returns 0 as well, although if glCheckFramebufferStatus returns 0 > an error code should be set. ... If you can provide a reproducable case for this, please open a new bug report. I don't see how this could happen with the current code.
The game starts on wine-1.0.1 (unfortunately the performance is horrible and there are lots of missing textures). It still segfaults on 1.1.19, this might well be a wine regression. I'll try the latest -git version and file a ticket in wine bugzilla.
(In reply to comment #5) > ... > > If you can provide a reproducable case for this, please open a new bug report. > I don't see how this could happen with the current code. > I didn't investigate this much on the Mesa side, but the logs in http://bugs.winehq.org/show_bug.cgi?id=19417 show indirect rendering is being used. I suspect that's the case for the other report as well. Are FBOs supposed to be supported in that case?
*** This bug has been marked as a duplicate of bug 23335 ***
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.