Android Screen rotation crash

[mrpantalon]

Hi,
When the smartphone is rotated, the app crash came with backtrace : http://pastebin.com/DepbhSvE

My code is the code of android samples.
Lib compiled with NDK rev 9c and android gcc 4.8 + stlport

[MarioLiebisch]

Possibly related:
With the activity's android:screenOrientation set, the crash no longer happens, but the app crashes or gets stuck (black screen) if you use the home button (Nexus 5; see below).

Backtrace when actually crashing:

I/DEBUG   (  180): backtrace:
I/DEBUG   (  180):     #00  pc 0000e630  /system/lib/libc.so
I/DEBUG   (  180):     #01  pc 00006b53  /data/app-lib/com.example.sfml-1/libsfml-system.so
I/DEBUG   (  180): 
I/DEBUG   (  180): stack:
I/DEBUG   (  180):          753e8680  00000000  
I/DEBUG   (  180):          753e8684  00000000  
I/DEBUG   (  180):          753e8688  00000000  
I/DEBUG   (  180):          753e868c  00000000  
I/DEBUG   (  180):          753e8690  00000000  
I/DEBUG   (  180):          753e8694  00000000  
I/DEBUG   (  180):          753e8698  00000000  
I/DEBUG   (  180):          753e869c  00000000  
I/DEBUG   (  180):          753e86a0  00000000  
I/DEBUG   (  180):          753e86a4  00000000  
I/DEBUG   (  180):          753e86a8  00000000  
I/DEBUG   (  180):          753e86ac  00000000  
I/DEBUG   (  180):          753e86b0  00000000  
I/DEBUG   (  180):          753e86b4  00000000  
I/DEBUG   (  180):          753e86b8  00000000  
I/DEBUG   (  180):          753e86bc  00000000  
I/DEBUG   (  180):     #00  753e86c0  753e86fc  [stack:3827]
I/DEBUG   (  180):          753e86c4  74e47320  [anon:libc_malloc]
I/DEBUG   (  180):          753e86c8  75fea49c  [anon:libc_malloc]
I/DEBUG   (  180):          753e86cc  753e8788  [stack:3827]
I/DEBUG   (  180):          753e86d0  753e86fc  [stack:3827]
I/DEBUG   (  180):          753e86d4  74f1fb57  /data/app-lib/com.example.sfml-1/libsfml-system.so
I/DEBUG   (  180):     #01  753e86d8  753e86fc  [stack:3827]
I/DEBUG   (  180):          753e86dc  74f1d349  /data/app-lib/com.example.sfml-1/libsfml-system.so (sf::Mutex::lock()+8)
I/DEBUG   (  180):          753e86e0  753e86fc  [stack:3827]
I/DEBUG   (  180):          753e86e4  74f1d2f9  /data/app-lib/com.example.sfml-1/libsfml-system.so (sf::Lock::Lock(sf::Mutex&)+12)
I/DEBUG   (  180):          753e86e8  74e47344  [anon:libc_malloc]
I/DEBUG   (  180):          753e86ec  74f2cb8f  /data/app-lib/com.example.sfml-1/libsfml-window.so
I/DEBUG   (  180):          753e86f0  00000000  
I/DEBUG   (  180):          753e86f4  00000000  
I/DEBUG   (  180):          753e86f8  00000000  
I/DEBUG   (  180):          753e86fc  74e47344  [anon:libc_malloc]
I/DEBUG   (  180):          753e8700  74f1fbc1  /data/app-lib/com.example.sfml-1/libsfml-system.so
I/DEBUG   (  180):          753e8704  753e8788  [stack:3827]
I/DEBUG   (  180):          753e8708  75fea478  [anon:libc_malloc]
I/DEBUG   (  180):          753e870c  75fea49c  [anon:libc_malloc]
I/DEBUG   (  180):          753e8710  00000001  
I/DEBUG   (  180):          753e8714  74f29389  /data/app-lib/com.example.sfml-1/libsfml-window.so (sf::VideoMode::getDesktopMode()+8)

Edit:
Following is the backtrace/stack when the crash happens with fixed orientation and the switch to the home screen. This seems to be a race condition, since it doesn't happen all the time.

I/DEBUG   (  180): backtrace:
I/DEBUG   (  180):     #00  pc 000090e6  /system/lib/libandroid.so
I/DEBUG   (  180):     #01  pc 00004703  /data/app-lib/com.example.sfml-1/libsfml-example.so
I/DEBUG   (  180): 
I/DEBUG   (  180): stack:
I/DEBUG   (  180):          bee3a460  41561c4c  /system/lib/libdvm.so
I/DEBUG   (  180):          bee3a464  6d4a5fa0  /dev/ashmem/dalvik-LinearAlloc (deleted)
I/DEBUG   (  180):          bee3a468  00000000  
I/DEBUG   (  180):          bee3a46c  405e0000  /system/lib/libft2.so
I/DEBUG   (  180):          bee3a470  415811f0  /system/lib/libdvm.so
I/DEBUG   (  180):          bee3a474  414cff68  [anon:libc_malloc]
I/DEBUG   (  180):          bee3a478  41577582  /system/lib/libdvm.so
I/DEBUG   (  180):          bee3a47c  00000000  
I/DEBUG   (  180):          bee3a480  bee3a4b0  [stack]
I/DEBUG   (  180):          bee3a484  414d1408  [anon:libc_malloc]
I/DEBUG   (  180):          bee3a488  00000000  
I/DEBUG   (  180):          bee3a48c  6d43bb60  
I/DEBUG   (  180):          bee3a490  bee3a504  [stack]
I/DEBUG   (  180):          bee3a494  74f1fb57  /data/app-lib/com.example.sfml-1/libsfml-system.so
I/DEBUG   (  180):          bee3a498  00000438  
I/DEBUG   (  180):          bee3a49c  74f1d349  /data/app-lib/com.example.sfml-1/libsfml-system.so (sf::Mutex::lock()+8)
I/DEBUG   (  180):     #00  bee3a4a0  00000000  
I/DEBUG   (  180):          bee3a4a4  00000000  
I/DEBUG   (  180):          bee3a4a8  00004001  
I/DEBUG   (  180):          bee3a4ac  752d8707  /data/app-lib/com.example.sfml-1/libsfml-example.so
I/DEBUG   (  180):     #01  bee3a4b0  74e484f4  [anon:libc_malloc]
I/DEBUG   (  180):          bee3a4b4  00000001  
I/DEBUG   (  180):          bee3a4b8  414cff68  [anon:libc_malloc]
I/DEBUG   (  180):          bee3a4bc  00000007  
I/DEBUG   (  180):          bee3a4c0  00000000  
I/DEBUG   (  180):          bee3a4c4  00000000  
I/DEBUG   (  180):          bee3a4c8  74e48688  [anon:libc_malloc]
I/DEBUG   (  180):          bee3a4cc  752d86e9  /data/app-lib/com.example.sfml-1/libsfml-example.so
I/DEBUG   (  180):          bee3a4d0  414d1408  [anon:libc_malloc]
I/DEBUG   (  180):          bee3a4d4  00000000  
I/DEBUG   (  180):          bee3a4d8  6d43bb60  
I/DEBUG   (  180):          bee3a4dc  401ba3e5  /system/lib/libandroid_runtime.so
I/DEBUG   (  180):          bee3a4e0  00000000  
I/DEBUG   (  180):          bee3a4e4  000000db  
I/DEBUG   (  180):          bee3a4e8  00000438  
I/DEBUG   (  180):          bee3a4ec  000006f0  

[MarioLiebisch]

Okay, update - my previous assumption has been (partially) wrong. What I know now:

When the screen rotates, the native window as well as the activity are destroyed and the app is restarted (I'm not sure that's intentional).

In MainAndroid.cpp inside onDestroy() states is deleted. However, this won't reset the copy of the pointer kept by sf::priv::getActivity(). Due to this non-window modules (like sf::VideoMode::getDesktopModes()) will still try to access the now invalid memory area, which results in the segfault.

By resetting the pointer to NULL in onDestroy() I was able to avoid the crash, however now the app restarts when the screen rotates, plus there still seems to be some race condition when hitting the home button while rotating (or rotating after returning from the home screen?).

Edit: My changes can be found in commit 27d2c7a. Feel free to toy around with it.

[LaurentGomila]

When the screen rotates, the native window as well as the activity are destroyed and the app is restarted (I'm not sure that's intentional).

If I remember correctly, adding to the manifest that the app handles screen rotations (or using a fixed orientation) gets rid of this behaviour. To be confirmed.

[MarioLiebisch]

It does, I just wasn't sure that's the behind-the-scenes difference (other than seeing the animation play and the screen resizing).

[intjelic]

The code is good enough, especially since, in the SFML context, no one should remove configChange:"orientation|screenSize" from his manifest file, and thus no one should run across this crash.

Regular Android application (written in Java using the Android API, and thus at higher level) would want the system to reselect the appropriate resources and rebuild the entire UI according to the new screen size/orientation. That's why Android restart the whole activity by default when these events occur.

Here, those reasons aren't applicable to a native Android application, and by consequences one should never prefer his whole app to restart when there's a screen rotation event or the screen size is modified.

[eXpl0it3r]

@sonkun can this issue be closed or is this not implemented yet?

[ghost]

I've added orientation to configChanges and set screenOrientation="landscape" in my manifest, my app crashes with a segfault when exiting. The same crash happens when you rotate the screen as when you go to the home screen when your app is in landscape, the rotation back to portrait causes the segfault. If I disable landscape and use the home button from portrait orientation, no crash. Any idea why this is?

[TankOs]

What's the status of this? Didn't fix #641 the original issue? I'm no Android expert, but from what I understood, when people don't change the manifest, nothing will blow up?

[MarioLiebisch]

Haven't tested it lately, but it should. Even if not, wouldn't call it a blocking issue, just document the recommended manifest details (see Sonkun's post above) somewhere.

[TankOs]

Alright, thanks again. I set this to 2.x. I know that @sonkun is assigned, but since this only triggers when people change the manifest, and regarding the fact that the iOS and Android ports are not even stable/complete, I think this is an acceptable solution for pushing 2.2 forward.

If someone wants to fix this for 2.2 in a reasonable amount of time, then I guess nobody has something against it. But this and the other related issues have been around for months, so I think postponing them is a valid consequence.

[eXpl0it3r]

Removed milestone due to missing progress.

[mantognini]

Is this still a bug or was it fixed a long time ago and the issue was forgotten? (Probably @MarioLiebisch knows?)

[MarioLiebisch]

It's an edge case. This more or less only is an issue if you don't try to handle rotation inside SFML (same with #644). Proper documentation can "fix" this (as commented above).