We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 5244 - App crashes on resuming from closing Chromebook laptop
Summary: App crashes on resuming from closing Chromebook laptop
Status: NEW
Alias: None
Product: SDL
Classification: Unclassified
Component: *don't know* (show other bugs)
Version: 2.0.10
Hardware: Other Other
: P2 critical
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-27 08:23 UTC by Florian B
Modified: 2020-07-31 19:07 UTC (History)
1 user (show)

See Also:

Attachments
Error dump (592 bytes, text/plain)
2020-07-27 08:23 UTC, Florian B 		Details
logcat (4.79 KB, text/plain)
2020-07-30 07:54 UTC, Florian B 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Florian B 2020-07-27 08:23:36 UTC 
Created attachment 4427 [details]
Error dump

Running our app (SDL 2.0.10 powered game) on a Chromebook (ChromeOS, not listed above), we encountered a crash. Repro steps :
- run the app
- close laptop, putting it to sleep
- reopen laptop, should wake up on the app, resuming
- app crashes after briefly displaying the last frame registered

We have tracked down the issue, and the onResume() event of the SDLActivity.java is effectively triggered. It ultimately leads to handleNativeThread() to be called. Then, either the SDL thread is null and we be recreated (without checking for errors at any point) or it exists and will be resumed. It crashes at this point during the thread execution / revival with a SIGSEGV (signal 11).

Attached, an error dump with a very brief backtrace, stating the error occurred while running code from libEGL_mesa.so.

It happened only on Chromebook, not on Android / iOS / tvOS (other platforms we've run the exact same code on).

Due to confidentiality reasons, can't post code or samples, sorry
Comment 1 Sylvain 2020-07-28 07:01:57 UTC 
hello,

Can you try with latest SDL2 head source from mercurial https://hg.libsdl.org/SDL/

then, is this always reproducible ?
could you provide a logcat ? and maybe add more traces ?
check you AndroidManifest.xml so that the activity has only one instance.
Comment 2 Florian B 2020-07-30 07:54:17 UTC 
Hi.

Tested with SDL2 latest, making the activity a single instance one. Crash still occurs (with a lower reproduction rate it seems). 
It takes between 10 and 30 tries before getting it. Not a high reproduction rate, I know :/
Happens consistently on 2 different chromebooks. We tried disabling as much as possible of our java code and remove dependencies, did not change the situation in any way.

Attached a logcat extract. 
Could you please tell me which information interest you the most ? I would then be able to add traces and provide an extended logcat then.
Comment 3 Florian B 2020-07-30 07:54:43 UTC 
Created attachment 4428 [details]
logcat
Comment 4 Sylvain 2020-07-30 12:50:12 UTC 
Sorry I'd like to see a *full* log cat so that I see what happens when it enters sleeping mode (onCreate onPause etc.). (maybe you can also a provide a full good logcat).


maybe there will be traces to add in SDL: src/core/android/SDL_android.c
nativePause(), nativeResume() etc.

also the backtrace is strange: 
2020-07-29 15:48:44.365 A/DEBUG: backtrace:
2020-07-29 15:48:44.365 A/DEBUG:     #00 pc 00013d21  /vendor/lib/egl/libEGL_mesa.so
Comment 5 Florian B 2020-07-31 13:51:42 UTC 
I see, will do my best to add relevant traces (huge workload right now tbh).

Regarding the backtrace strangeness : yes indeed. Seems OpenGL code is to blame ?
Comment 6 Sylvain 2020-07-31 19:07:33 UTC 
Don't know whether it's opengl or something. something wrong when chromeos goes into sleep mode, does the app is fast enough to react ?

maybe, it would be a good idea to state with just an helloworld app.
and to make sure the BG/FG event are receive correctly.