Crash on startup (v59) #5850
Comments
|
Cleaned up stack trace: |
|
Btw why is there no crash dialog when the app crashes? Normally you can send in crashes for apps to the devs, but here I need to manually report this on github by writing an ADB log over USB with android studio. That means hardly any crash will be reported by the users, as most don't even know what adb means. |
|
Native crashes never resulted in a crash dialog (also for Tangram). I think there is not much that can be done. |
|
It does look the same as the second crash I was having in If you look at my report against
So, it might be that those were two different bugs which just happen to be triggering by the same conditions. (after looking some more) And they don't always trigger in unison. When they do, Java seems to log error before JNI, but I've had cases where just Java got triggered, and cases where just JNI got triggered. (I haven't had a crash in |
|
Any additional information on how to reproduce this issue (after starting from a clean slate, i.e. fresh install) could be helpful. |
Well, I can't. I don't wanna clean my settings and add all quest profiles again - if possible. I was using SC 59 alpha 1 for a day or two, until it started crashing more and more on startup and then I couldn't start it again without crashing. Now I just updated to alpha 2 and can't start it either. |
|
@Helium314 wrote:
How about adding something like Google Breakpad to capture the crash in the native code? |
I have not taken a deep dive; but I don't think their LICENSE(s) are compatible with StreetComplete's GPLv3. But IMHO, those frequent and irrecoverable native crashes should be resolved before the beta is released to more general public who might not know how to use adb/logcat. So by the time it gets to them, there should hopefully be no native crashes of significance...
Interesting, it might mean that more downloaded data mans higher crash possibility? Should try that.
That is unfortunate, but such is a fate of alpha-software testers. Complete data loss, crashes etc. is frequent occurrence here. I would not recommend anyone using alpha (or even beta) versions as their daily driver; unless they're comfortable with the fact that software will likely be significantly buggy. My solution is that I use a lot of presets on my older Tangrem-ES SCEE on my main phone (which do not get nuked at all), and test with StreetComplete alphas (without bothering much if at all with saving/restoring presets). For testing SCEE, I use old phone or build my own devel version (like this one, which can run at the same time alongside official SCEE releases. You, or anyone else, if free to use them, or use GitHub actions to compile their own easily). So perhaps some arrangement like that might work for you? (i.e. keeping StretComplete/SCEE on stable version, and using "yellow" debug builds for actual testing, where losing data is not a big deal) |
But can we exclude that this crash is not only happening because the app finds itself in this erroneous state now due to the now fixed other crash issue from alpha1? Only if it is possible to reproduce the issue while maplibre/maplibre-native#2432 has already been fixed there's a chance that maplibre/maplibre-native#2779 will get fixed, I suppose. |
|
@RubenKelevra |
This comment was marked as outdated.
This comment was marked as outdated.
I'm not sure how to answer this question. I mean, I wiped the cache. So only things in the data portion could lead to this crash. So what would the alpha 1 write in the data section which would lead to a crash in the alpha 2, which the alpha 2 would not write there? |
|
🤷♂️ |
|
Fetching the bugreport via adb does work. Sorry, haven't scrolled down that far. Apart from that: I can write system traces, which would you have a peek in the things the system and the app did before the crash. It's not really a trace, but you can see at which things did complete and which not - if that's helpful? |
|
TBH I don't know what is helpful and what is not. I have no experience whatsoever debugging native crashes. It is best if you asked this question at maplibre/maplibre-native#2779 |
|
Okay, so the bugreport created is absolutely useless for the issue. It does not contain any tombstone files or crash logs for street complete - sadly. :/ As the device is not rooted, I also can't simply access the tombstones files in the shell. I could of course wipe the data section, but if I can't reproduce the issue I can't confirm a fix either. |
Indeed, good point. |
|
I think the null pointer dereference might be related to some map-data SC wants to render. So something in the map data in the already stored data is uncommon, that's why it's crashing for me and nobody else atm. And that's why it worked a while, and then I moved the map view to an area with the issue and then it crashed. That's the general area where I was with the SC view the last time. Maybe someone else can download the general area and pan and zoom around to see if it's crashing? |
|
I did, but no crash. (Also, tabbed out of the app for a while and came back later to it, because that triggered the other issue sometimes) |
|
Hm maybe you could add a debug message very early in the program start, to print out the view point in lat/lon/zoom, while the map data is loaded? This could potentially show us which data might be responsible, before the app crashes. And is more reliable than my memory what I might have looked at the last time I started the app. |
|
I don't think it has anything to do with location. |
RubenKelevra
changed the title
|
I can confirm that Version 59.0 alpha4 is still crashing for me - so it wasn't caused by not updating a component because of caching in the build-process. |
I mean that's the only thing which makes sense to me, why I could use the app for a while and then it refuses to start. It will just repeatedly try to render a section of map which it can't do. |
|
Okay, it's worth a try. |
|
https://www.westnordost.de/misc/StreetComplete-v59.0-alpha4-Ruben.apk Look in the log for the line tagged with "#5850" on startup. |
|
lol, that's a completely different country, than I thought it was. I remember now, I've checked if the rendering error (#5006) is still there. We even got a screenshot how it looked shortly before I closed it: |
It never occurred again after the first wipe of user data, so it might or might not be related to what's happening to the other users here. |
Yep, that's right. Nothing works. I can wipe the data and after something like 24 hours the app will start to crash 100% of the time. |
|
MapLibre 11.5.0 with a potential fix for this issue is available. |
|
@westnordost if you create a test build I'll check it out :) |
|
This may sound weird, but it's 50% fixed. 😅 As I've said before, I created a secondary version of the same app with a feature called "dual apps". So the difference is the data/cache of the app is different, but the APK itself is the same. My regular SC now opens fine so far (I've tried it twice after installing 59. 1, no crash), but the app with barely any data, just 2-3 areas downloaded max and no login will still crashes on startup. I know it works fine in 59.0 if I clean the data, but after around 24 hours it will consistently crash 100% of the time. Edit: So after a couple of tries more the secondary installation now also starts. It crashes however on every 8-10th startup on average. The main installation (which got a lot more downloaded data/tiles) seems not crashy. So it may be fixed and we're running sometimes into a different bug now? I don't know. I'll write a log tomorrow to see what's going on. |
|
vs.59.1 still crashes on startup. Android 13, Xiaomi Mi 11 Lite 5G |
|
The stack trace looks the same, though. I think it is the same issue. |
|
Here's my crash log: |
|
Nice! Could you submit this to the upstream issue + tombstone? |
|
@westnordost tombstone files are not accessible for me, as my device is not rooted. Done. |
@RubenKelevra Hm, neither is mine so I cannot access filesystem directly, but following this instructions: https://developer.android.com/studio/debug/bug-report#bugreportdevice I was previously able to acquire tombstones (and other data) on my Android 13. It just needs enabling |
|
Yeah I tried this, but it doesn't work on my device. The bug report contains some other crash files, but no tombstone files - sadly. I can only trigger them on my device via adb, so maybe they are then a bit different. Or Android 12 with MIUI is just weird. Here's what I said about this above: #5850 (comment) |
|
I'd just like to add that the 59.1 release still crashes on me. Felt compelled to mention it to make it clear that it isn't a one-user issue. |
|
Yes, this is currently the cause of 98.6% of all crashes in StreetComplete. About 10% of all sessions are affected, i.e. it crashes on start on average 1/10 times according to statistics shown on Google Play Developer Console. |
|
Hope this works |
|
MapLibre 11.5.1 with another potential fix for this issue is available. |
|
Alright, time for another release. I am waiting for it to appear on the Maven repository |
|
@westnordost if you like I can do a quick check if it will fix it :) Just link a dev APK, like last time |
|
It's fine, I'll just do a normal release. Some enhancements and other fixes have been contributed, too. |
|
With 59.2 I can open the app again, but this happend on the last update, too. But after one or two days it was back to crashing again. So we have to wait a while until we can be sure that it's fixed :) |
|
Still looks fixed to me. :) |
|
That took a load off my mind! Finally, we can move on! 🥳 |
59 alpha 2 still crashes for me on startup. I've attached the log (filtered for "streetcomplete")
Log
startup_crash.log
How to Reproduce
Expected Behavior
Versions affected
Android 12
SC Version 59.0 alpha2
The text was updated successfully, but these errors were encountered: