Bug 44405

Summary: Spring RTS crashes using r600g (5670, Redwood), kernel rejects relocations
Product: Mesa Reporter: Marcin Baczyński <marbacz>
Component: Mesa coreAssignee: mesa-dev
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: medium CC: aguz_114, brianp, jfonseca
Version: git   
Hardware: Other   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: gdb bt full
glxinfo
Backtrace generated with ABRT

Description Marcin Baczyński 2012-01-02 16:23:45 UTC
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.
Comment 1 Marcin Baczyński 2012-01-02 16:24:22 UTC
Created attachment 55061 [details]
glxinfo
Comment 2 Michel Dänzer 2012-01-03 10:48:47 UTC
Looks like Gallium/Mesa core confusion about whether pipe_surface is a screen or context object.
Comment 3 Marcin Baczyński 2012-01-04 11:43:21 UTC
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?
Comment 4 Alex Deucher 2012-01-05 06:27:26 UTC
this might be related to bug 44239.
Comment 5 Marek Olšák 2012-01-05 07:39:33 UTC
Could you please make a trace file using apitrace[1]? Please make the trace
with:

[1] https://github.com/apitrace/apitrace
Comment 6 Marcin Baczyński 2012-01-05 11:15:00 UTC
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"
Comment 7 Marek Olšák 2012-01-05 12:29:53 UTC
przeklej.pl requires registration. Can you upload it somewhere else or maybe send it to my email?
Comment 8 Marcin Baczyński 2012-01-05 12:39:52 UTC
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.
Comment 9 Marcin Baczyński 2012-01-05 13:42:22 UTC
Here's another try (the same trace): http://www.megaupload.com/?d=62QDBN10
Comment 10 Jerome Glisse 2012-02-22 10:13:29 UTC
Still an issue with more recent r600g/mesa ?
Comment 11 Marcin Baczyński 2012-02-23 10:35:37 UTC
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
Comment 12 Michel Dänzer 2012-04-02 02:53:36 UTC
*** Bug 48179 has been marked as a duplicate of this bug. ***
Comment 13 Agustin Ferrario 2012-04-04 16:18:42 UTC
Created attachment 59496 [details]
Backtrace generated with ABRT

The bug was also reproduced in spring 88. I generated this bactrace with Fedora's ABRT
Comment 14 Vadim Girlin 2012-04-06 10:37:11 UTC
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.
Comment 15 Agustin Ferrario 2012-04-08 16:49:42 UTC
Thaks for that i think i will try it, if it works for me i'll report it in Spring Mantis
Comment 16 Jose Fonseca 2012-04-09 02:20:29 UTC
(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.
Comment 17 GitLab Migration User 2019-09-18 20:22:59 UTC
-- 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.