Crash on startup AndroidRendererFrontend #2779
Comments
I can't... What device? Can you get us a tombstone? Or a fully symbolicated stack trace? |
|
I don't know how to get a tombstone or a fully symbolicated stack trace. The crash was already observed with 11.1.0 and observed in conjunction with #2432 (i.e. just after) but also independent of each other (see this comment: streetcomplete/StreetComplete#5850 (comment)). One device with which it had been reproduced was Samsung Galaxy S23+ on Android 14. The other is some Xiaomi device on Android 12. See streetcomplete/StreetComplete#5829 (comment) :
The user which can now reliably reproduce the crash on every app start is now in this exact situation. |
|
(In any case, we have one user who can reliably reproduce this crash on every app start. We could provide him with a modified version of the app which can generate a fully symbolicated strack trace, only I don't know what would need to be done for this.) |
|
I thought I would be able to recover the last two frames with the debug symbols we publish alongside the release, but I have not had any luck with that. Android has guides Debug native Android platform code and Diagnose native crashes. I hope it is not needed to make a custom build. @mnalis Could you try this? https://developer.android.com/studio/debug/bug-report And see if it generates a tombstone? |
louwers
changed the title
|
@louwers actually it is the other user that is currently having issues with new But as that particular crash looks the same, here is my (Samsung Galaxy S23+, Android 14) example tombstone (made via Hopefully it helps, or at least give information if special debug build will be required to collect more info... |
Redmi Note 10 Pro running Android 12
Nope, it's not rooted, so I can't access the tombstone directory.
How do I do this? Just run the app build with full debug symbols and capture the log? |
|
@westnordost wrote:
@westnordost Can you build be version with this line set to false and added to the block? |
|
@louwers Here's the crash log: |
|
Thanks. The last two frames are still not included. Maybe we can try this: https://f-droid.org/docs/Reproducible_Builds/#native-library-stripping Could be that we need to change something on our end. |
Could try that, but I understand that first the PR you created must be merged and a new maplibre version released , right? |
|
I got a very similar crash on startup (only once). Release apk without the above changes for debugging, but at least I have root access and thus a tombstone file. |
|
Somehow our build seems to be stripping symbols from the core library. They are also not part of the debug symbols in the tar file part of the release. Need to try to understand what Gradle is doing here and how I can get these symbols… |
This line is YOLO-casting a |
So, would adding some debug logging around that place help locate the source of the problem; or is existing information enough to devise a solution/workaround to avoid the crashes? |
|
@mnalis from my quick glimpse at the code it should be checked if the return is zero and then waited and retried until it's fully initialized. Or get loop handle should block with a lock until it can return a good value. |
|
I didn't manage to trace down how a loop handle could be uninitialized, but I will add some defensive programming and throw an exception instead of crashing when |
|
If I can run some special debug version or something, I'm happy to do so, if that helps. Thanks for the work! |
|
Maybe the custom thread local implementation is returning a null pointer here. void* ThreadLocalBase::get() const {
return pthread_getspecific(reinterpret_cast<const pthread_key_t&>(storage));
}I replaced it with Worth a try. |
|
@RubenKelevra Could you try 11.5.0? |
|
Unfortunately, it is not fixed in 11.5.0. A stack trace for a user using StreetComplete with MapLibre native 11.5.0: Since StreetComplete with MapLibre has been released publicly last week, I now have insight into some statistics.
Since this happens a lot, it is curious why this issue hasn't surfaced before with other MapLibre users. StreetComplete must be using some feature that few MapLibre users use or in a way that few MapLibre users do. Users report that clearing the app's data (sometimes) help. |
|
It's the same line as #2779 |
So there's a change, as I can start the app and use it like 8 or 9 out of ten startups. But at one startup I still get a crash. Previously it was 100% crash rate, except with clean app data - then it worked for a day or two and then it started crashing. My guess was some kind of cleanup process is started if the last cleanup is like 24 hours ago, to check for old downloaded data in the app - or something similar, as the pattern was pretty consistent. Meaning, that this has not a direct effect on maplibre, but makes some of the maplibre setup processes run slower and triggering this race condition. Here's my log: |
|
Apparently |
|
@RubenKelevra @westnordost 11.5.1 is now out, which hopefully resolves this problem. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
On app startup, a user reported that the following crash occurs:
To Reproduce
Maybe you can reproduce it too in this release:
https://github.com/streetcomplete/StreetComplete/releases/tag/v59.0-alpha2
Platform information:
See also
streetcomplete/StreetComplete#5850
The text was updated successfully, but these errors were encountered: