Bug 44405

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.