Created attachment 55060 [details] gdb bt full I'm using Mesa from git(77058335), r600g on Redwood [Radeon HD 5670], kernel 3.1.5. Spring crashes on startup, with following trace(full trace attached) #7 0x00007fd1b9f858d5 in pipe_surface_reference (ptr=0x7fd1ae5a1a58, surf=<optimized out>) at ../../src/gallium/auxiliary/util/u_inlines.h:112 #8 st_renderbuffer_delete (rb=0x7fd1ae5a19b0) at state_tracker/st_cb_fbo.c:181 #9 0x00007fd1b9f59c30 in _mesa_reference_renderbuffer_ (ptr=0x7fd1ae596998, rb=0x0) at main/renderbuffer.c:186 #10 0x00007fd1b9f30b1e in _mesa_reference_renderbuffer (rb=0x0, ptr=0x7fd1ae596998) at main/renderbuffer.h:62 #11 _mesa_free_framebuffer_data (fb=0x7fd1ae596740) at main/framebuffer.c:216 #12 0x00007fd1b9f30bfe in _mesa_destroy_framebuffer (fb=0x7fd1ae596740) at main/framebuffer.c:193 #13 0x00007fd1b9f30cb3 in _mesa_reference_framebuffer_ (ptr=0x7fff6a0c34a8, fb=0x0) at main/framebuffer.c:253 #14 0x00007fd1b9f2c304 in _mesa_reference_framebuffer (fb=0x0, ptr=0x7fff6a0c34a8) at main/framebuffer.h:62 #15 _mesa_DeleteFramebuffersEXT (n=1, framebuffers=<optimized out>) at main/fbobject.c:1832 and with lots of similar messages in dmesg: [14960.505619] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x136 [14960.505622] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! [14960.524494] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x136 [14960.524497] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! [14960.758968] unknown[16452]: segfault at 0 ip 0000000000a84204 sp 00007fff3e6ac280 error 4 in spring[400000+d4a000] attached full trace and glxinfo. Let me know if you need more info.
Created attachment 55061 [details] glxinfo
Looks like Gallium/Mesa core confusion about whether pipe_surface is a screen or context object.
Glad you know what's wrong in there. Is there anything I can do to help fixing this bug? Like some traces or debug dumps?
this might be related to bug 44239.
Could you please make a trace file using apitrace[1]? Please make the trace with: [1] https://github.com/apitrace/apitrace
Apitrace-generated trace file: http://www.przeklej.pl/plik/spring-trace-xz-003alv6au7tb (~15MiB compressed) Apitrace shows some warnings while tracing, don't know if it matters here though. apitrace: warning: unknown function "glXGetSwapIntervalMESA" apitrace: warning: unknown function "glXSwapIntervalMESA"
przeklej.pl requires registration. Can you upload it somewhere else or maybe send it to my email?
Ah, sorry, should've checked that. Some time ago they didn't, apparently they changed their minds. Email sent, and I'll upload it somewhere else later.
Here's another try (the same trace): http://www.megaupload.com/?d=62QDBN10
Still an issue with more recent r600g/mesa ?
With todays 4a72d859b it still crashes. [ 3344.322850] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x12f [ 3344.322853] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! $ addr2line -f -e /usr/lib/dri/r600_dri.so < /tmp/addrs pipe_surface_reference /data/mesa/src/mesa/../../src/gallium/auxiliary/util/u_inlines.h:112 _mesa_reference_renderbuffer_ /data/mesa/src/mesa/main/renderbuffer.c:158 _mesa_free_framebuffer_data /data/mesa/src/mesa/main/framebuffer.c:218 _mesa_destroy_framebuffer /data/mesa/src/mesa/main/framebuffer.c:194 _mesa_reference_framebuffer_ /data/mesa/src/mesa/main/framebuffer.c:249 _mesa_DeleteFramebuffersEXT /data/mesa/src/mesa/main/fbobject.c:1786
*** Bug 48179 has been marked as a duplicate of this bug. ***
Created attachment 59496 [details] Backtrace generated with ABRT The bug was also reproduced in spring 88. I generated this bactrace with Fedora's ABRT
AFAICS the game uses additional gl context for loading the resources in the separate thread. After destroying that context some pipe_surface is destroyed in the "pipe_surface_reference" using the "surf->context->surface_destroy" function pointer from the already destroyed context. There is a workaround - multithreaded loading can be disabled by adding "LoadingMT = 0" to the game config (~/.springrc). With default "LoadingMT = -1" the game disables multithreaded loading if the gl renderer string contains "mesa" or vendor string contains "intel". I guess the game developers might want to check for "gallium" too. Also there is another issue, probably not related - there are few asserts checking the width/height to be > 0 (in the guess_base_level_size and st_texture_create), while the app uses zero width/height for some textures. IIRC the gl spec allows zero dimensions. The debug build of the game fails on these asserts.
Thaks for that i think i will try it, if it works for me i'll report it in Spring Mantis
(In reply to comment #14) > AFAICS the game uses additional gl context for loading the resources in the > separate thread. After destroying that context some pipe_surface is destroyed > in the "pipe_surface_reference" using the "surf->context->surface_destroy" > function pointer from the already destroyed context. > > There is a workaround - multithreaded loading can be disabled by adding > "LoadingMT = 0" to the game config (~/.springrc). Brian recently looked into this sort of issues. He commited a few workarounds, which might have help here too. But an extensive cleanup will be necessary to fully address this issue.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/971.
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.