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 3933 - Android, no need of the listener thread
Summary: Android, no need of the listener thread
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: *don't know* (show other bugs)
Version: don't know
Hardware: All Android (All)
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-01 20:20 UTC by Sylvain
Modified: 2017-11-02 15:46 UTC (History)
0 users

See Also:


Attachments
patch (1.89 KB, patch)
2017-11-01 20:20 UTC, Sylvain
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sylvain 2017-11-01 20:20:01 UTC
Created attachment 3054 [details]
patch

With 

https://hg.libsdl.org/SDL/rev/a9c5ddad50b0
https://hg.libsdl.org/SDL/rev/c197a316685a

A listener thread has been added to know when the native thread would end.
But now, it is more easy to only check that after the main function has returned. It's one thread less.
Comment 1 Sam Lantinga 2017-11-02 00:31:58 UTC
Does this handle the case when the native thread crashes?
Comment 2 Sylvain 2017-11-02 08:38:45 UTC
I tried and what I get is:

Currently with the ThreadListener:

- null pointer dereferencing in C will crash the whole activity.

- calling a java method that throw an exception uncaught
If  you have a single jni call, app still runs, but when returning from SDLMain, at the end, there is a : 

E AndroidRuntime: FATAL EXCEPTION: SDLThread
E AndroidRuntime: 	at org.libsdl.app.SDLActivity.functionThatCrash(Unknown Source)
E AndroidRuntime: 	at org.libsdl.app.SDLActivity.nativeRunMain(Native Method)
V SDL     : onPause()
V SDL     : nativePause()
V SDL     : onWindowFocusChanged(): false
V SDL     : surfaceDestroyed()
V SDL     : onDestroy()

It crashes, but Activity seems to terminate normally. Though at the end, there a pop-up "Would you like to restart the application!".

If you have several jni calls, they will crash the activity because of the exception.

Same behavior with my patch ...

We could add a sigaction handler to catch the sigsev, but I don't think that's a good idea. Apps should just be debugged ...
We could check exception after each jni call, I don't think that's a good idea neither. Exception should be caught within the java side.
Comment 3 Sam Lantinga 2017-11-02 15:46:38 UTC
Sounds good, thanks!
https://hg.libsdl.org/SDL/rev/cb780bb5093a