Destroying SDL_Renderer in app background event with the intention to restore it in foreground event leads to crash #1424
Comments
ghost
mentioned this issue
ghost
self-assigned this
|
Did you ever work this out? Is it a p4a or sdl2 issue? Did SDL 2.0.9 maybe affect it? |
|
@inclement yes the crash is definitely still happening, although not triggered only by renderer change (that just seems to make it more likely). I was simply busy with other things, but before I release my app I'll have to debug this and find out. It's some race condition with leaving & coming back I suspect it's a bug in either SDLActivity.java, PythonActivity.java or SDL2 native code. Can't say more without debugging it deeper |
|
Did you use a background service ? For me, It s look like it try to resume the service |
|
@brvier nope, none of that at all, just a boring "regular" app. (I haven't even checked out how to do a service yet) However it occurred to me that in recent time I have become one of the active python-for-android contributors best suited to debug this. (since I poked around so much in SDL2 for the recent big upgrade) So I'll bite, I just haven't gotten around to it yet. No need to invest time unless you're curious or you want to solve this crash faster for yourself 👍 |
Both in fact :) |
Could this be related https://bugzilla.libsdl.org/show_bug.cgi?id=4142 |
|
Not sure, now that I'm looking at the backtrace again, it actually looks like it's crashing inside python and not in libSDL2. (which I would expect if this was a synchronization issue in some internal SDL2 data structure) I think the only way to find out what is really happening is to check in gdb |
Crash occur in initandroidembed of start.c for me ... |
|
I'm just thinking, if you see this right at the app start you should probably file a separate ticket. The crash here was purely when returning to the app when it was in background in between, so if that is not what you're getting it's probably something different Also I just noticed I could no longer reproduce it since I revamped some of my SDL_Renderer code to never touch things while in background & after bumping the SDL2 version to fix something unrelated: #1779 So it appears whatever I saw was either my own fault, or an SDL2 bug. Are you still seeing crashes, and when exactly are they occurring for you? (app launch, or later?) |
|
Yes indeed, i was making more test, but this is not related. The crash i got is in fact two disctinct bugs :
|
|
Oops, the web form ate half my comment, here it is again: Okay, could you possibly create tickets for these then? Because I think what I saw is gone, so it's probably the most reasonable approach if I close this ticket now
For what it's worth, that sounds like it is probably not easily avoidable / might be an inherent NDK issue. So I wonder if that's not a bug but just something the app needs to avoid doing...? But maybe the others got some input on that (for what it's worth, python has these daemon threads that get auto-terminated when the main thread exits. maybe using something like that would help?) Or does that also happen if the other threads exit with a small delay? That would indeed be quite a problem |
|
Ok, thanks for the feedback! I'll close this ticket then |
Versions
Description
What happens:
Destroying SDL_Renderer in app background event with the intention to restore it in foreground event leads to crash. I tested this on multiple devices, so this is most certainly not a GPU driver bug, but something in either p4a's wrapper or SDL2's SDLActivity that is broken.
The crash happens when you go back into the app inside the wrapper with access to address 0x8 before the app resume event / custom app code happens, so right before control is returned to my own app code.
There is a small chance of the crash not happening, and if it doesn't, everything will work fine from then on in any followup background & resume events. So it seems to be some sort of race condition.
Why would anyone want this to work:
The reason to do this in the first place is to avoid buggy GPU drivers that don't keep the 3d context around, so accessing the SDL_Renderer after background & restore would lead to a crash - hence, the dumping and recreation to avoid that. However, with p4a this doesn't work right now due to this crash.
Why aren't all apps affected by this:
I'm pretty certain kivy is unaffected because it neither uses SDL_Renderer, nor seems to destroy & recreate the context in such a way.
buildozer.spec
not used, but my requirements are not including kivy, just plain SDL2
Logs
The text was updated successfully, but these errors were encountered: