*dst_px in SDL_PremultiplyAlpha() is inaccessible when setting cursor under wayland - causing "Bus error" #9256
Comments
|
@Kontrabant, why would shared memory generate a bus error here? |
|
Two possibilities offhand:
To see if it is the latter issue, you can try adding an fsync() after the ftruncate() call here: Both of these issues resulted in similar problems for others at some point. We should probably use memfd_create(), if available, before trying to open a real file to avoid potential problems like this. |
|
I'm betting that it's the no space issue. The way this works now, a temporary file is created and the size is set with ftruncate(), which doesn't return an error if there is insufficient space for the requested file size. I'm modifying this to open the temporary file with These functions aren't 100% portable (the more niche BSDs may lack them), but the existing codepath still exists as a fallback. |
Hey so I think you are right that it is the no space issue. When I run my pygame program, if any of the code uses pygame.mouse.set_cursor (which in turn calls the appropriate SDL equivalent), a very large amount of "sdl-shared-xxxxx" files are created, and it quickly fills up the tmpfs (XDG_RUNTIME_DIR), as shown below: The files are not deleted when the program closes (I'm assuming they should be, though I'm not entirely sure how tmpfs works (edit: after some research it seems like they are only removed when the user session ends)). I'm assuming this isn't normal behavior (correct me if I'm wrong). Is this an issue with pygame's implementation of set_cursor, or is related to SDL directly? Thanks for looking into this. |
|
From looking at pygame's source, it seems to create a brand new SDL cursor object each time set_cursor is called. I imagine that's not very efficient if it's called every frame.. but it also does have code to free the previous one so any leak might not be in pygame itself. |
|
Alas, it was a case of user error...
That was exactly what I was doing... I had unwittingly put my calls to set_cursor() in my game loop, which explains this:
Sorry for the trouble.. |
|
If pygame is cleaning up properly when calling set_cursor (which I think it is, but I didn't look too closely) then I'd still find it surprising that a bunch of resources build up like that rather than just one or even a small number that evens out over time. |
|
No trouble at all. Actually, this uncovered some bad behavior on the SDL side. We should be more robust against this than we are, and shouldn't be leaking those temp files. I have some pending changes to fix this. |
I don't know much about SDL at all from a technical perspective, but pygame's set_cursor() seems to be freeing the Cursor objects appropriately via SDL_FreeCursor(); however, I'd imagine shared memory files generated in $XDG_RUNTIME_DIR would need to be deleted explicitly (which I'm not even sure is something one should be doing to begin with), unless SDL_free handles that internally. I also noticed this: SDL/src/video/wayland/SDL_waylandmouse.c Lines 532 to 534 in d79f865 which is probably relevant - seems the author also wasn't sure what to do with them. |
|
Temp files being leaked is now fixed in SDL 2 and 3. |
|
And I cherry-picked to release-2.30.x, thanks! |
|
The SDL2 autotools build needed to be updated with the checks for memfd_create() and posix_fallocate() as well. Done. |
System Specs:
I am not familiar at all with the inner-workings of SDL, though I interact a lot with it indirectly via pygame, which is a python wrapper for many SDL functions.
When I try to set a cursor to some surface, I get a fatal "Bus error". This doesn't happen all the time, and restarting my PC always fixes it. However, the issue returns unexpectedly, and seemingly at random.
Here is a minimal reproducible example in pygame:
The following is the backtrace of the program:
I did some digging with gdb, and it seems the exception is raised here on this line:
SDL/src/video/SDL_surface.c
Line 1799 in d79f865
which is called here:
SDL/src/video/wayland/SDL_waylandmouse.c
Lines 459 to 462 in d79f865
If I am understanding correctly,
data->shm_data, when casted to aUint32 *is not accessible. This corresponds with the following gdb output:I suspect this to be a wayland/kwin/kwin-bismuth issue, but I am not confident in troubleshooting this enough to be sure.
Here is a relevant part of
journalctloutput:If anyone could help me troubleshoot this, I would appreciate it.
The text was updated successfully, but these errors were encountered: