Rare(?) random(?) crash on Android

[Jupeyy]

When joining my local server.
Maybe even just the first time you start the client with a clean config
Had this on arm32 and arm64 once

This is the automatic crashlog by the system:

#00 pc 0025f304  /data/app/~~PVFkvZvFDwwN7N0zxGQQsQ==/tw.ddnet-XCT0CsAzPtEC0qNAsYjcng==/lib/arm/libDDNet.so (BuildId: db32789a9f7c269ad5706e80a3a5227cfe70b10d)
08-16 00:52:14.883 27115 27115 F DEBUG   :       #01 pc 0018aa87  /data/app/~~PVFkvZvFDwwN7N0zxGQQsQ==/tw.ddnet-XCT0CsAzPtEC0qNAsYjcng==/lib/arm/libDDNet.so (CConsole::ExecuteLineStroked(int, char const*, int, bool)+1130) (BuildId: db32789a9f7c269ad5706e80a3a5227cfe70b10d)
08-16 00:52:14.883 27115 27115 F DEBUG   :       #02 pc 002503ad  /data/app/~~PVFkvZvFDwwN7N0zxGQQsQ==/tw.ddnet-XCT0CsAzPtEC0qNAsYjcng==/lib/arm/libDDNet.so (CBinds::OnInput(IInput::CEvent)+372) (BuildId: db32789a9f7c269ad5706e80a3a5227cfe70b10d)
08-16 00:52:14.883 27115 27115 F DEBUG   :       #03 pc 002e3771  /data/app/~~PVFkvZvFDwwN7N0zxGQQsQ==/tw.ddnet-XCT0CsAzPtEC0qNAsYjcng==/lib/arm/libDDNet.so (CGameClient::OnUpdate()+336) (BuildId: db32789a9f7c269ad5706e80a3a5227cfe70b10d)
08-16 00:52:14.883 27115 27115 F DEBUG   :       #04 pc 001f5ad3  /data/app/~~PVFkvZvFDwwN7N0zxGQQsQ==/tw.ddnet-XCT0CsAzPtEC0qNAsYjcng==/lib/arm/libDDNet.so (CClient::Update()+3914) (BuildId: db32789a9f7c269ad5706e80a3a5227cfe70b10d)
08-16 00:52:14.883 27115 27115 F DEBUG   :       #05 pc 001f6ce3  /data/app/~~PVFkvZvFDwwN7N0zxGQQsQ==/tw.ddnet-XCT0CsAzPtEC0qNAsYjcng==/lib/arm/libDDNet.so (CClient::Run()+2062) (BuildId: db32789a9f7c269ad5706e80a3a5227cfe70b10d)
08-16 00:52:14.883 27115 27115 F DEBUG   :       #06 pc 001fb5e1  /data/app/~~PVFkvZvFDwwN7N0zxGQQsQ==/tw.ddnet-XCT0CsAzPtEC0qNAsYjcng==/lib/arm/libDDNet.so (SDL_main+1584) (BuildId: db32789a9f7c269ad5706e80a3a5227cfe70b10d)
08-16 00:52:14.883 27115 27115 F DEBUG   :       #07 pc 005a4918  /data/app/~~PVFkvZvFDwwN7N0zxGQQsQ==/tw.ddnet-XCT0CsAzPtEC0qNAsYjcng==/lib/arm/libDDNet.so (Java_org_libsdl_app_SDLActivity_nativeRunMain+664) (BuildId: db32789a9f7c269ad5706e80a3a5227cfe70b10d)

[Jupeyy]

I tracked it down to ConKeyInputCounter in CControls.
Where pState->m_pControls->GameClient() is a NULL pointer.
But I don't see how this can be possible, so it is probably a overflow somewhere

[def-]

A random memory overwrite would be quite bad. Is it possible to run with asan on android?

[Jupeyy]

It should be(https://developer.android.com/ndk/guides/asan), but on my arm phone I didnt get this to work back then.
Dunno if clang has something like -fsanitize-undefined-trap-on-error.
Would maybe already help.

[Jupeyy]

Ok, managed to make it run under android 11 and 10, but nothing useful from asan
arm showed random stuff, sometimes use-after free, sometimes double free, also at random locations
the two arm64 devices also showed different locations, one showed an offset in libddnet, one in libc.
Honestly no clue how to debug it, maybe it's a bug outside of ddnet, SDL or one of the other libs, strange that it also mostly happens when i randomly click on the screen when connecting,
but all happened after the map was loaded at showed for a few frames

Under the emulator i couldn't reproduce it at all

[def-]

Might be timing related if it doesn't happen in emulator. Some race condition. But not sure how to figure out more, thread sanitizer might be worth a shot.

[Jupeyy]

the ndk seems to not support it yet.

Anyway I tracked the issue down before SDL_main function is even called, so it's either a global variable or an issue outside of DDNets scope, I'll just try some SDL versions or other versions for the other libs.
It also doesn't happen all the time, really random ^^

I'll set this issue as goal for the pr

[Jupeyy]

Ok apparently (non const, globally initialized) global variables under android are generally dangerous, didn't know
https://discourse.libsdl.org/t/android-onresume-not-called-should-it-be-called/21547/14

That's from 2015, but that's actually something i see in the debugger too, and might be one of the issues

[Jupeyy]

Ok i fixed it with std::exit, just required to not use SDL_Quit at std::atexit