Crash on startup (v59.0) #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: |
|
Zoomed to that town, downloaded data, enabled parking overlay. Didn't crash for me. |
|
Alright, thanks for checking! Btw it didn't crash while using. It only crashed while reopening the app. |
|
Since noone else seemed to have been able to reproduce this crash, I am inclined to release v59.0-beta1 soon (without a fix for this issue), hoping that it occurs reasonably rarely. It seems that Bart has been able to "unpack" the necessary debug information from the stack traces already, so for debugging you'd not need to keep the app in the faulty state, i.e. you could clear the data and try if the issue persists for you. |
I've also tried opening that location with
Would it be fine to push beta1 to f-droid too? (as a non-preferred version, of course) |
Well, I've used the Dual Apps function in MIUI to install the alpha 4 a second time. I just downloaded some areas and moved around on the map yesterday, today I can't open the second, clean installation either. https://github.com/user-attachments/assets/f426d189-3093-4b28-806f-7c37d43aab76 |
That is interesting. Could you tell us details what exactly you were doing (in SC and switching out, clearing the recents etc?), and how long it took, and at what point did it crash? Did you change any options from default? Logged in? Was any overlay active this time? Were you doing manual downloads on only automatic ones that follow GPS? how large were download areas and how many there were? were they overlapping or disjointed? etc., any information you can remember. I've been using Also, did you check if the new crash log is the same ( |
No login, no overlays, no settings changed, just opened the app, moved to Poland, downloaded two areas manually. Closed the app, reopened it (2x) - no crash Today: I tried to open -> crash The issue which was found by the dev of the library points to a race condition where a section of the lib is not yet fully initialized, returning a null pointer instead of a initialized function. So it depends on the execution speed of the app if that happens or not, which would explain why its happening on some devices more often than on others. It's also definitely only a cold startup issue. |
I can check that as soon as I'm home. |
Same. Here's the log I promised: |
RubenKelevra
changed the title
|
Can confirm the crashes on startup for 59 beta 1 as well :) |
|
Unfortunately, so has 59.0-beta1 crash logMy last upload was 2024-09-08 03:48 UTC with I might have left the app somewhere in the settings, but also could be in the main screen or in the middle of some quest. Then on 2024-09-10 16:49 CEST (so same day, some 14+ hours later) I tried to start StreetComplete again, and it crashed with error above. Subsequnt start several dozen seconds later worked automatically, and didn't ask me to send error log (which is normal due to the native crash IIRC). When it crashed, I didn't have pending new quests (my SC is in manual upload mode) That is about all I remember. |
|
And here is a "share log" from app, which contains information from before and just after the crash (i.e. whole 2024-09-10): share log (with times in UTC?) |
|
Yeah first time this happend to me like for you now: I could just startup the app again. But a day later it would not start up again at all. And I could never get it to crash just once again. Great to hear that it seems to be the same bug, not a different one causing this. |
|
This looks like a (perhaps) interesting part of the log: above is the end of my first normal try of I was not using SC at this time, so this This above seems to be startup of |
|
The cleaner only removes stuff from the SC database, it does not affect MapLibre. |
|
@mnalis could very well be that something like the cleaner is what changes the startup enough to cause the crash, as it's a race condition. Could also be just the background load on the system at the moment of startup affecting the likelihood of it occurring. As far as I understand the issue has been identified and they are working on a fix now. |
|
And I think nobody is surprised that I can confirm the issue with version 59 gamma as well :) |
|
Yeah, I am sorry to hear that. For the sake of our users I hope you just have particularly bad luck and it doesn't happen that often or persistently for others. The good news is that I noticed that the maintainer of maplibre-native assigned the reported crash issue to himself (and already investigated and found the point in the code where the crash happens), so maybe he will investigate further and provide a fix, soon. If not, since this seems to be a race condition, we could investigate if there is a workaround for this, like pausing initialization for a few hundred milliseconds somewhere. |
|
I think a workaround may make sense, as it will likely block some people from using the app. From what I can tell it seems to be related with some function of SC which isn't triggered on all startups. Reason being I can clean the data, start the app, download stuff, close the app completely (with the force button) and restart it - no problem. But tomorrow I won't be able to start it anymore. So my guess is that some cleanup function or something like this checking the cached tiles or cached OSM data or something like this after x hours or 1 day or so have elapsed from the last startup and this is what's more likely to cause the race condition. Does this ring a bell? |
It has happened to me 2 times more since my last report a week ago (once in 59.0-beta1, and once just after upgrading to release of 59.0). Both times it was only single crash (i.e. on restart SC started normally), but still... it sounds uncomfortably often (especially since I was not particularly active in last week, maybe a dozen or two quests every day or two)... Just to check, native crashes are not reported even in Google Play version (IIUC it has different crash reporting than f-droid one)? |
|
Well a thing I've not yet mentioned is, that it tries to open a "application has crashed" window for a split second, where you can hit report - but it seems to cancel this right away again, before the "show up" animation is yet shows completely. So no, no reporting happening on the Google Play version as well. The users are basically locked out after the update after a day - from what I can tell - if they run into the issue as severe as I am. |
When Updating from 59.0-beta1 (installed from apk) to 59.0 (installed from Google Play) my SC kept crashing. I wasn't able to get any log whatsoever and could only resolve this by deleting all locally stored data - which wasn't a problem as I don't keep unuploaded changes for ages as other users do - do it was annoying to go through the intro stuff again and re-login... Sadly I cannot contribute anything other meaningful info to why that happened. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: