Now just grey screen of death

[jidanni]

Vespucci now refuses to start anymore. It says loading. Then we switch to a gray screen. And then after a few seconds we're back into our cell phones launcher. Yes I tried clearing the cache in Android app settings. logcat.txt:

"05-04 14:51:23.629 I/TileLayerSource(4648): Trying to read custom imagery from /storage/emulated/0/Download/Vespucci/imagery.geojson 05-04 14:51:26.915 I/l7.h (4648): Loading downloaded preset, directory=/storage/emulated/0/Download/Vespucci/autopreset 05-04 14:51:26.930 I/ (4648): No usable old MRU list, creating new one (java.io.FileNotFoundException: /storage/emulated/0/Download/Vespucci/autopreset/mru.dat (No such file or directory)) 05-04 14:51:26.936 D/MRUTags (4648): Loading from /storage/emulated/0/Download/Vespucci/mrutags.xml 05-04 15:00:26.919 I/TileLayerSource(10065): Trying to read custom imagery from /storage/emulated/0/Download/Vespucci/imagery.geojson 05-04 15:00:29.555 I/l7.h (10065): Loading downloaded preset, directory=/storage/emulated/0/Download/Vespucci/autopreset 05-04 15:00:29.565 I/ (10065): No usable old MRU list, creating new one (java.io.FileNotFoundException: /storage/emulated/0/Download/Vespucci/autopreset/mru.dat (No such file or directory)) 05-04 15:00:29.569 D/MRUTags (10065): Loading from /storage/emulated/0/Download/Vespucci/mrutags.xml 05-04 15:01:21.194 D/LauncherLog(10286): AppsCustomizePagedView - syncAppsPageItems page: 3 index: 60 Item: Vespucci" content://ru.zdevs.zarchiver.external/storage/emulated/0/Android/data/ru.zdevs.zarchiver/files/logcat.txt#:~:text=05%2D04%2014,60%20Item%3A%20Vespucci

[jidanni]

I would go into the menus but I can't get to them.

[jidanni]

https://vespucci.io/tutorials/reporting_issues/ seems to say I should have seen some prompt about reporting crashes. But when this happens. There is nothing. We're just back on the launcher screen. Thus there is no opportunity to send any crash information in. Android 8 ASUS.

[simonpoole]

I would suggest restarting your phone.

[simonpoole]

https://vespucci.io/tutorials/reporting_issues/ seems to say I should have seen some prompt about reporting crashes. But when this happens. There is nothing. We're just back on the launcher screen. Thus there is no opportunity to send any crash information in. Android 8 ASUS.

You are not getting a crash dump prompt because it isn't vespucci crashing.

[jidanni]

In https://vespucci.io/tutorials/faq/ we see several tips about just clearing out the app's data.

But there is no mention there that this will also wipe out your passwords and all your preferences etc

It seems the only hope is just to wait for the next upgrade

That way we don't have to uninstall the app and lose all our preferences etc.

[simonpoole]

In https://vespucci.io/tutorials/faq/ we see several tips about just clearing out the app's data.

But there is no mention there that this will also wipe out your passwords and all your preferences etc

There is no mention of that because there is no mention or suggestion of uninstalling / wiping data outside of the tile cache.

[jidanni]

I tried restarting the cell phone but that didn't fix the problem.

I'm not going to take the step of clearing the app's data because this is a valuable opportunity where we can fix this problem.

The FAQ says

To recover from the directory containing the tile database not being writable you do not need to re-install Vespucci, simply clearing the apps data in your application manager is enough. If the problem is related to access to a removable storages, disabling the "Prefer removable storage" in the Advanced preferences "Layer download and storage" section may help.

Anyway you need to warn people that they're going to see this message

To resolve you can clear all the data for the app (upload any pending changes before that), or you can try to simply remove the database file,. The location is typically (on removable storage or on the internal "sdcard") in Android/data/de.blau.android/files/databases/ remove osmaptilefscache_db.db and the accompanying journal file too

Indeed only at the very end do we see that it is only talking about the tiles.

[simonpoole]

If restarting didn't help you can try re-installing the version you already had installed to rule out that the problem is caused by corruption of the binary on device.

[simonpoole]

Indeed only at the very end do we see that it is only talking about the tiles.

You mean except for the big fat titles.

[jidanni]

https://support.google.com/googleplay/answer/113410 mentions reinstalling but it doesn't seem possible.. will probably need adb. Thus will probably have to wait half a month for laptop access at my friend's house.

[simonpoole]

You can try downloading the apk from the repo and installing that, as it is signed with the same key as the google play store build it should just work.

[jidanni]

Okay it going to take a while to find the actual dot APK link on https://github.com/MarcusWolschon/osmeditor4android/releases/tag/19.0.0.3

[jidanni]

It looks like I'll just have to downgrade in order to get the APK: https://github.com/MarcusWolschon/osmeditor4android/releases/tag/18.1.5.0

Well okay I'll downgrade then I can upgrade again from Google play.

Or maybe I should wait a moment and somebody could put the apks there on the newer versions' GitHub pages.

[jidanni]

Wait I found https://github.com/MarcusWolschon/osmeditor4android/releases/download/19.0.0.1/vespucci-19.0-BETA-1-signed.apk That's not too old. I'll try that! In fact it's the version I am currently trying to use.

[jidanni]

Okay I reinstalled it from the apk. Unfortunately nothing has changed. It is still the same 3 seconds of loading presets then 20 seconds of a gray screen then 3 seconds of the launcher and the spinner and then we're back looking at all the app icons in the launcher.

The only part of the app that still functions, is if in the launcher we pressed long on the app and then the widget choices show up and we can at least still look at the help part of the app.

[jidanni]

Check your mailbox or whatever to see if the app is actually sending a lot of crisis messages to you. There should be about 20 of them all coming from an Asus cell phone.

[simonpoole]

There are no crash reports, I'll check the play store for ANRs but you would have got the corresponding Android modal in that case. The log excerpt doesn't indicate anything out of the ordinary except the last entry which I suspect is from the launcher you are using. Does the log contain everything till the loading stops? (Is the phone rooted btw?)

Just to start ruling out things, I would suggest renaming the Vespucci directory in the Download folder.

[simonpoole]

I'll check the play store for ANRs but you would have got the corresponding Android modal in that case.

As expected no ANRs.

[jidanni]

Indeed it creates a new Downloads/Vespucci before it gets stuck.

[jidanni]

Okay in Matlog logcat I instead used the keyword "blau" and found much more details.

[simonpoole]

Essentially that indicates that the app was killed by the system potentially because of an OOM event. Do you have the full log up to 17:12:13.618 ? Likely the interesting bits are not tagged with the apps package name.

Did you have a lot of GPX layers loaded?

[jidanni]

Here is a fresh logcat that definitely has everything.

[jidanni]

I think I had one GPX layer, that's been there for weeks and isn't very large.

[simonpoole]

So the full log clearly shows that the app starts up correctly and the relevant main state files are all loaded successfully. The next thing that happens is that the app is killed (no crash dump or similar). Have you installed any app killers or does your version of android has something like that installed, potentially this could be in the developer preferences. Any other new installed apps.

I would rename the GPX file, but I don't see any reason in the log that that would link that to the issue.

[jidanni]

Turning off battery optimization for this app, https://www.howtogeek.com/762936/how-to-stop-android-from-killing-background-apps/amp/ didn't help.

I'm thinking perhaps that the app gets into some infinite loop,

while(1){}

So something else, maybe the kernel, kills it.

Maybe you could test in an internal version of Vespucci. Where in preferences you could put a button to cause an infinite loop.

[jidanni]

Maybe it was getting some file from the network and the network had a problem so it only got half the file. And then every time it tries to read that file there's some loop that gets caused.

I guess I'll have to take a look at the end of the month when I can use ADB, and then can proceed and give you a report on what all the internal files look like.

[simonpoole]

External files should all have been read by the time the app gets terminated, essentially the only candidate would be the GPX file in any case (which why I suggested to rename it, just to rule that out). If you didn't configure a layer that references something online then there is nothing that would cause any network accesses (outside of the downloading OSM data etc).

[jidanni]

Here we see the screen that we stare at for 20 seconds.

The first problem is, couldn't this screen have some words on it, like "please wait" or something?

Okay, I suppose that we are only supposed to see the screen for about a half a second. And the reason why it takes 20 seconds, is there must be that infinite loop going on.

We also notice in the upper left corner two icons. One is for a screenshot that I recently took. The other is for https://play.google.com/store/apps/details?id=simple.batttery.alarm .

Now, the amazing thing is, after Vespucci disappears and we are back staring at the launcher, that second icon is gone from the top of the screen!

I checked the running processes listing and it's definitely not running at all anymore.

So whatever is killing Vespucci is also killing it.

(It is an alarm that will tell me when my battery is charged to 99%. I have it start every time upon power up.)

Yes maybe it is some Google Play Services thing that is doing this. But I stopped all its processes, but then they started up again anyway...

But still, I'm very curious if you have Vespucci do some infinite loop, will it recreate the situation as in here?

(I also checked and there's no GPXs on this cell phone. They were on a different cell phone.)

[simonpoole]

Android 8 ASUS.

Is this a zenfone 3? If it is, seems as if an ANR report has arrived on googles play store from roughly 28 hours ago which could fit. However you never mentioned getting the ANR modal.

[jidanni]

Yes. Zenfone 3! I was going to mention it. But you know what happened? I was going to copy the GitHub bug number into the little place where it asks me for comments but by the time I switched back to the screen, it was gone, so I assume you never got it.

In fact of the many times I ran the program there was only one time it caused the anr. All the others were just simply the app disappearing after 20 seconds.

[simonpoole]

In fact of the many times I ran the program there was only one time it caused the anr.

And did you wait? (from the sump there is no indication that anything specific is going on it is simply drawing a way, deep in Androids library code).

[jidanni]

It asked me if I wanted to add any comments. So I switched to the other window to copy the GitHub bug number, and when I switched back it was gone.

Anyway, please see if you can reproduce it by simply making an infinite loop. https://stackoverflow.com/questions/3332656/is-it-possible-to-detect-an-endless-loop First start with a simple infinite loop. Then if after 20 seconds that doesn't get killed, then add some battery hungry behavior to it also.

The more bad behavior you can add into it the sooner whatever police force is doing a killing will wake up and then kill all the wasteful jobs. In fact as you saw it killed more than one, it killed my other app too.

And if this all actually is successful and reproduces the behavior, then we'll think about ways to fix it.

[simonpoole]

It asked me if I wanted to add any comments.

I was referring to the ANR modal.

Anyway, please see if you can reproduce it by simply making an infinite loop.

An infinite loop will lock up your phone and do all kind of bad things, there is no need to test that. You seem to be forgetting that it is -your- phone doing this, not that of anybody else, so unless you want to send your phone here, you need to stop wild speculation and provide more facts so that we can narrow down what could potentially be causing the issue. For example where you were editing before this occurred. This doesn't imply that there is anything happening that is under our control, actually everything up to now would indicate it isn't.

[simonpoole]

Note that beta 3 is available now, not likely to help, but I would still suggest installing it.

[jidanni]

You are right, updating didn't help.

I do notice one new thing: if I switch away from Vespucci during the 20 seconds, the other app doesn't get killed.

Okay, at the end of the month, using adb, I'll compare the file system, with the APK's file system.

I think on the dreadful day that started happening, I was switching on and off my Wi-Fi at the time.

[jidanni]

Looking at logcat, we see even the launcher itself gets killed,

05-07 01:39:57.650 I/ActivityManager(1542): Process com.asus.launcher (pid 11401) has died: vis BFGS

https://developer.android.com/reference/android/app/AppOpsManager apparently involved.

[jidanni]

Just a guess... https://stackoverflow.com/questions/7316680/process-has-died

[simonpoole]

That thread is 11 years old and has no bearing on the issue.

[jidanni]

( Skype was also crashing. Removing updates to market://details?id=com.google.android.webview fixed that, but not Vespucci. )

[AntonKhorev]

There is a bug with restoring map data. If there are ways with triangles on the side, indicating which side is down, Vespucci for some reason may fail to load the data. Since there's no way to refuse data loading at start, it's going to be impossible to launch Vespucci without clearing the data (and losing logins, settings, layers). It will get stuck either on gray screen or on "loading data into memory".

I knew that embankments are one kind of such lines and that I have to be careful when editing places with those. But now v19 comes out and starts rendering triangles on retaining walls too...

[simonpoole]

There is a bug with restoring map data. If there are ways with triangles on the side, indicating which side is down, Vespucci for some reason may fail to load the data.

That has previously never been reported.

It would seem to be unlikely that the issue has to do with restoring the data, as the saved state doesn't actually include the stying information, but could be something going on with rendering after a restore.

[AntonKhorev]

v19.0.0.0 fdroid: load a place with retaining walls, manually restart Vespucci - crash at 'loading data' or gray screen

downgrade to v18.1.5.0: load the same place (which now renders differently), restart - everything works ok

[simonpoole]

v19.0.0.0 fdroid: load a place with retaining walls, manually restart Vespucci - crash at 'loading data' or gray screen

downgrade to v18.1.5.0: load the same place (which now renders differently), restart - everything works ok

This is not reproducible here, neither with 18.1 with embankments nor with 19.0 with retaining walls. Not saying that it isn't happening for you, but there must be further circumstances that cause this to happen.

Can you provide some further details, for example a link to an area / object with which you've had the issue, and what do you exactly understand under "manually restarting"?

Please supply device and Android version too, thank you.

[simonpoole]

ping @AntonKhorev

[AntonKhorev]

• tablet with Android 6.0 (Lenovo TAB 2 A10-70L) - crashes on data with embankments
• phone with Android 7.0 (Samsung Galaxy A3) - same
• maybe it works on newer devices?
• crashes also happen on Vespucci 17.0.1.0, although it doesn't seem to render triangles for embankments
• Vespucci 16.1.2.0 doesn't crash on embankments
• "manually restarting" = Android settings > Apps > Vespucci > Force stop

[AntonKhorev]

Vespucci 16.1.3.0 crashes. So it's some change between 16.1.2.0 and 16.1.3.0. I installed older versions from F-Droid Archive repository.

[simonpoole]

@AntonKhorev it is fairly clear that your issue doesn't have anything to do with this one. As a temporary workaround I would suggest using a datastyle without path patterns.

[AntonKhorev]

@AntonKhorev it is fairly clear that your issue doesn't have anything to do with this one. As a temporary workaround I would suggest using a datastyle without path patterns.

Not so clear to me. When my crash happens it also kills other apps. I'm not sure if @jidanni tried clearing the data. If he tried and it didn't help, then maybe it's a different issue.

[simonpoole]

I just tested on an Samsung S5 with Android 6.0.1 no problems. A concrete example of real OSM data where the issue happens would be really useful.

• "manually restarting" = Android settings > Apps > Vespucci > Force stop

You should never do this except if the app is really hanging, it will end with potential corruption of state files and so on. To exit the app completely simply press the back button.

[AntonKhorev]

Pressing back button twice and restarting Vespucci doesn't cause the crash.