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

[simonpoole]

When my crash happens it also kills other apps.

This sounds very much like an Android issue, do you have any developer options turned on?

[AntonKhorev]

I took this data style https://github.com/MarcusWolschon/osmeditor4android/blob/master/src/main/assets/styles/Color-round.xml , made a new style by deleting all pathPattern attributes. No crashes now.

Tested here: https://www.openstreetmap.org/#map=19/59.94890/30.30730

[AntonKhorev]

This sounds very much like an Android issue, do you have any developer options turned on?

I have USB debugging on.

[AntonKhorev]

Turned off developer options on the tablet where I haven't modified styles - still crashes.

[AntonKhorev]

I first encountered this crash when I edited this park last year: https://www.openstreetmap.org/relation/2653740#map=16/59.9444/30.3368

I suspected that there's something in the data that Vespucci doesn't like. I started to download smaller areas to find where the crash happens. Eventually I narrowed it down to this embankment way: https://www.openstreetmap.org/way/1002092895 Then I was able to replicate it on any empty place where I add only an embankment way and restart Vespucci. I kept editing the park making sure Vespucci is not restarted until the edit is done. I was going to report this issue but then crashes stopped even when I had the entire park loaded. Maybe adding something to the data can negate whatever causes the crash? So I forgot about it for a while.

Later I was editing this place with retaining walls https://www.openstreetmap.org/#map=19/59.93138/30.29245 I updated to Vespucci 19.0.0.0 and it crashed.

[simonpoole]

I've been able to recreate this (after a forced stop) in the area you pointed to, see https://github.com/MarcusWolschon/osmeditor4android/issues/2298 Right now it simply seems to be an issue with Skia.

Please continue the discussion there are it clearly doesn't have anything to do with @jidanni issue.

[jidanni]

OK, now using

adb backup de.blau.android #no root needed, then
{ echo =1F=8B=08=00=00=00=00=00=|
 qprint --decode; tail --lines=+5 backup.ab;\
 echo =00=28=00=00=; }|tar xzvf - #no checksums
find apps -type f -size +1c -print0|xargs -0 ls -got

I see the last file written before the problems started seems to be

-rw-r----- 1     212 04-26 22:49  apps/de.blau.android/f/bookmarks.ser.backup

Looking around for similar files,

$ find apps -type f -size +1c -print|grep -i book
apps/de.blau.android/ef/other/bookmarks.geojson
apps/de.blau.android/f/bookmarks.ser.backup

Here we find four names,

$ json_pp -json_opt pretty,canonical <
 apps/de.blau.android/ef/other/bookmarks.geojson | grep name
            "name" : "DYY"
            "name" : "ND/MT"
            "name" : "paranaque lib"
            "name" : "rainbow bridge "

but in bookmarks.ser.backup.gz the last one seems to be missing...

bookmarks.ser.backup.gz

So maybe something about bookmarks is garbled.

Maybe the program should first scan the bookmarks to see they are OK, before attempting to use them... and crash. (Wild guess.)

In fact if you could release a new version that upon starting simply first checks the validity of the various files it reads in and prints error messages instead of 'getting stuck', then maybe such corruption wouldn't be 'ruin things forever'. (Again, just a wild guess. The program perhaps already checks...)

Anyway I can post the whole backup.ab here. Just tell me which file(s) have my password in it so I can edit it out. Thanks.

[Update: found: db/keys is the file that has tokens (not passwords)]

[simonpoole]

but in bookmarks.ser.backup.gz the last one seems to be missing... backup.der is the old save format for bookmarks and no longer used, see https://github.com/MarcusWolschon/osmeditor4android/blob/master/CHANGELOG.txt#L26

bookmarks.ser.backup.gz

So maybe something about bookmarks is garbled. Nope.

Maybe the program should first scan the bookmarks to see they are OK, before attempting to use them... and crash. (Wild guess.)

In fact if you could release a new version that upon starting simply first checks the validity of the various files it reads in and prints error messages instead of 'getting stuck', then maybe such corruption wouldn't be 'ruin things forever'. (Again, just a wild guess. The program perhaps already checks...)

Yes naturally "the program checks" and as we already established here https://github.com/MarcusWolschon/osmeditor4android/issues/2274#issuecomment-1534679733 that the program does read the state files correctly and that the hang is later on.

Anyway I can post the whole backup.ab here. Just tell me which file(s) have my password in it so I can edit it out. Thanks.

If you haven't entered a password in the preferences, which you shouldn't have for the standard OSM API, then we don't store any passwords in the app.

[simonpoole]

Revisiting the ANR report, it seems as if this could actually be related to the report from @AntonKhorev, just that you never mentioned anything about force stopping the app.

      #00  pc 0x00000000002df394  /system/lib64/libskia.so (SkPathRef::Editor::Editor(sk_sp<SkPathRef>*, int, int)+196)
      #01  pc 0x00000000002d6c7c  /system/lib64/libskia.so (SkPath::lineTo(float, float)+176)
      #02  pc 0x00000000002d9420  /system/lib64/libskia.so (SkPath::addPath(SkPath const&, SkMatrix const&, SkPath::AddPathMode)+172)
      #03  pc 0x0000000000340724  /system/lib64/libskia.so (SkPath1DPathEffect::next(SkPath*, float, SkPathMeasure&) const+452)
      #04  pc 0x0000000000340160  /system/lib64/libskia.so (Sk1DPathEffect::filterPath(SkPath*, SkPath const&, SkStrokeRec*, SkRect const*) const+128)
      #05  pc 0x00000000003402ac  /system/lib64/libskia.so (SkPath1DPathEffect::filterPath(SkPath*, SkPath const&, SkStrokeRec*, SkRect const*) const+60)
      #06  pc 0x00000000002d3c00  /system/lib64/libskia.so (SkPaint::getFillPath(SkPath const&, SkPath*, SkRect const*, float) const+104)
      #07  pc 0x0000000000272c3c  /system/lib64/libskia.so (SkDraw::drawPath(SkPath const&, SkPaint const&, SkMatrix const*, bool, bool, SkBlitter*) const+620)
      #08  pc 0x00000000001f26dc  /system/lib64/libskia.so (SkBitmapDevice::drawPath(SkPath const&, SkPaint const&, SkMatrix const*, bool)+92)
      #09  pc 0x00000000002113b0  /system/lib64/libskia.so (SkCanvas::onDrawPath(SkPath const&, SkPaint const&)+712)
      #10  pc 0x000000000025f86c  /system/lib64/libskia.so
      #11  pc 0x000000000051e608  /system/framework/arm64/boot-framework.oat (Java_android_graphics_BaseCanvas_nDrawPath__JJJ+168)
      at android.graphics.BaseCanvas.nDrawPath (Native method)
      at android.graphics.BaseCanvas.drawPath (BaseCanvas.java:298)
      at android.graphics.Canvas.drawPath (Canvas.java:1652)
      at de.blau.android.layer.data.MapOverlay.paintWay (MapOverlay.java:1401)
      at de.blau.android.layer.data.MapOverlay.paintOsmData (MapOverlay.java:562)
      at de.blau.android.layer.data.MapOverlay.onDraw (MapOverlay.java:463)
      at de.blau.android.layer.MapViewLayer.onManagedDraw (MapViewLayer.java:70)
      at de.blau.android.Map.onDraw (Map.java:606)
      at android.view.View.draw (View.java:19123)
      at android.view.View.buildDrawingCacheImpl (View.java:18371)
      at android.view.View.buildDrawingCache (View.java:18231)
      at android.view.View.draw (View.java:18843)
      at android.view.ViewGroup.drawChild (ViewGroup.java:4214)
      at android.view.ViewGroup.dispatchDraw (ViewGroup.java:4000)
      at android.view.View.updateDisplayListIfDirty (View.java:18064)
      at android.view.View.draw (View.java:18851)
      at android.view.ViewGroup.drawChild (ViewGroup.java:4214)
      at android.view.ViewGroup.dispatchDraw (ViewGroup.java:4000)
      at de.blau.android.views.SplitPaneLayout.dispatchDraw (SplitPaneLayout.java:373)
      at android.view.View.updateDisplayListIfDirty (View.java:18064)
      at android.view.View.draw (View.java:18851)
      at android.view.ViewGroup.drawChild (ViewGroup.java:4214)
      at android.view.ViewGroup.dispatchDraw (ViewGroup.java:4000)
      at android.view.View.updateDisplayListIfDirty (View.java:18064)
      at android.view.View.draw (View.java:18851)
      at android.view.ViewGroup.drawChild (ViewGroup.java:4214)
      at android.view.ViewGroup.dispatchDraw (ViewGroup.java:4000)
      at android.view.View.updateDisplayListIfDirty (View.java:18064)
      at android.view.View.draw (View.java:18851)
      at android.view.ViewGroup.drawChild (ViewGroup.java:4214)
      at android.view.ViewGroup.dispatchDraw (ViewGroup.java:4000)
      at android.view.View.updateDisplayListIfDirty (View.java:18064)
      at android.view.View.draw (View.java:18851)
      at android.view.ViewGroup.drawChild (ViewGroup.java:4214)
      at android.view.ViewGroup.dispatchDraw (ViewGroup.java:4000)
      at android.view.View.updateDisplayListIfDirty (View.java:18064)
      at android.view.View.draw (View.java:18851) 
      at android.view.ViewGroup.drawChild (ViewGroup.java:4214)
      at android.view.ViewGroup.dispatchDraw (ViewGroup.java:4000)
      at android.view.View.updateDisplayListIfDirty (View.java:18064)
      at android.view.View.draw (View.java:18851)
      at android.view.ViewGroup.drawChild (ViewGroup.java:4214)
      at android.view.ViewGroup.dispatchDraw (ViewGroup.java:4000)  
      at android.view.View.draw (View.java:19126)
      at com.android.internal.policy.DecorView.draw (DecorView.java:785) 
      at android.view.View.updateDisplayListIfDirty (View.java:18073)
      at android.view.ThreadedRenderer.updateViewTreeDisplayList (ThreadedRenderer.java:643)
      at android.view.ThreadedRenderer.updateRootDisplayList (ThreadedRenderer.java:649)  
      at android.view.ThreadedRenderer.draw (ThreadedRenderer.java:757)
      at android.view.ViewRootImpl.draw (ViewRootImpl.java:3010)
      at android.view.ViewRootImpl.performDraw (ViewRootImpl.java:2814)
      at android.view.ViewRootImpl.performTraversals (ViewRootImpl.java:2359) 
      at android.view.ViewRootImpl.doTraversal (ViewRootImpl.java:1394)
      at android.view.ViewRootImpl$TraversalRunnable.run (ViewRootImpl.java:6770) 
      at android.view.Choreographer$CallbackRecord.run (Choreographer.java:966) 
      at android.view.Choreographer.doCallbacks (Choreographer.java:778)
      at android.view.Choreographer.doFrame (Choreographer.java:713)  
      at android.view.Choreographer$FrameDisplayEventReceiver.run (Choreographer.java:952)
      at android.os.Handler.handleCallback (Handler.java:789) 
      at android.os.Handler.dispatchMessage (Handler.java:98)
      at android.os.Looper.loop (Looper.java:169)
      at android.app.ActivityThread.main (ActivityThread.java:6578)
      at java.lang.reflect.Method.invoke (Native method)
      at com.android.internal.os.Zygote$MethodAndArgsCaller.run (Zygote.java:240)
      at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:767)

[simonpoole]

19.0.2 adds a "Safe" shortcut that will set the data rendering style to the built-in minimal style (aka "black lines") and start the app. In my tests changing back to the regular style then works.

Note: shortcuts are only available on Android 7.1 and later.

[AntonKhorev]

Revisiting the ANR report, it seems as if this could actually be related to the report from @AntonKhorev, just that you never mentioned anything about force stopping the app.

"Force stopping" is only a way to reproduce the crash in controllable manner. The crash also happens when Vespucci fully restarts under normal circumstances: running other apps, updating Vespucci etc.

[jidanni]

Okay, the safe start mode allowed me to start it. And then I could start it some more, and then...

Okay, I guess if I just use the minimal mode I'll be okay.

[simonpoole]

You would waste a lot less of everybodies time if you would simply state what occurred.

Did the app crash? If it did, when did that happen, what did you change?

Seems as if it the report itself was caused by https://issuetracker.google.com/issues/62427912 which might be due to restarting apps that were opened in split screen mode. I would simply ignore it if it doesn't return.

java.lang.IllegalArgumentException: reportSizeConfigurations: ActivityRecord not found for: Token{fd4dd ActivityRecord{4d280b4 u0 de.blau.android/.Splash t-1 f}}
    at android.os.Parcel.readException(Parcel.java:1947)
    at android.os.Parcel.readException(Parcel.java:1889)
    at android.app.IActivityManager$Stub$Proxy.reportSizeConfigurations(IActivityManager.java:9333)
    at android.app.ActivityThread.reportSizeConfigurations(ActivityThread.java:2963)
    at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2906)
    at android.app.ActivityThread.-wrap11(Unknown Source:0)
    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1603)
    at android.os.Handler.dispatchMessage(Handler.java:105)
    at android.os.Looper.loop(Looper.java:169)
    at android.app.ActivityThread.main(ActivityThread.java:6578)
    at java.lang.reflect.Method.invoke(Native Method)
    at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:240)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:767)

And https://stackoverflow.com/questions/46309428/android-activitythread-reportsizeconfigurations-causes-app-to-freeze-with-black

[jidanni]

Just tell me, for Android 8, should we users always stay in minimal mode to be safe from now on? Thanks.

[simonpoole]

As I just pointed out here https://github.com/MarcusWolschon/osmeditor4android/issues/2274#issuecomment-1575124837 the crash was independent of rendering and likely only google knows what triggers it. If you are concerned about the rendering issue, you can use the style without path patterns. See https://github.com/MarcusWolschon/osmeditor4android/blob/19.0-MAINT/CHANGELOG.txt#L16

[jidanni]

Guaranteed way to reproduce the bug:

The following will leave the user just staring at a gray screen that does nothing:

• Use Android 8.0.
• Navigate to https://www.openstreetmap.org/?mlat=43.0900596&mlon=-79.0676052#map=16/43.09006/-79.06761 ... lots of data (including the mystery deadly item... Actually any rather densely mapped area will do) and Osmose items here.
• "Clear and Download Current View"
• In preferences choose Color Round Nodes.
• Background imagery doesn't matter. You can even choose "None".
• Stop and restart Vespucci.

This situation will persist, until the user uses the safe start mode to recover. Otherwise she will never be able to successfully start Vespucci again.

[simonpoole]

Guaranteed way to reproduce the bug:

We have already established what triggers the bug. As forced closing should only be used when there is no other way to proceed, it is easily avoided. google, as far as we have been able to determine, fixed the bug not quite 5 years back, so recent devices should not be affected. There is really not really anything that we can do about it other than offer a way to recover, which we have done

[jidanni]

Actually, the program could always open the app in minimal mode. And then after the app is fully open, turn on the Data Style that the user has in his preferences.

Because the problem seems to be only occurring when the app is launched, so all that needs to be done is get past the launch phase safely, and then you can restore the data style the user has in his preferences.

But wait, I guess the problem also happens when the user switches away from the window and that switches back perhaps too...

[AntonKhorev]

We have already established what triggers the bug. As forced closing should only be used when there is no other way to proceed, it is easily avoided.

Can you please forget about "forced closing"? The problem happens any time the app is fully restarted. It can be avoided by clearing the data before using other apps / updating Vespucci / rebooting the device.

[simonpoole]

The problem happens any time the app is fully restarted.

Not on any device that I have access to, you yourself confirmed that it didn't happen if you left Vespucci via the "back" button. If this is not correct please indicate if this happens on both your devices.

It can be avoided by clearing the data before using other apps

Running other apps doesn't really do anything different than exiting the app. Note that "clearing the data" simply works because if there is no data there is nothing to render so Skia wont crash, it doesn't have anything to do with restoring the data itself as the style information is not saved over invocations of the app.

updating Vespucci / rebooting the device.

Is Vespucci running when you are doing this? Because that is potentially equivalent to a forced close.

[AntonKhorev]

The problem happens any time the app is fully restarted.

Not on any device that I have access to, you yourself confirmed that it didn't happen if you left Vespucci via the "back" button. If this is not correct please indicate if this happens on both your devices.

It doesn't happen when you quit with back button. And it doesn't happen when you quit with back button AND force stop / run other apps etc after quitting this way.

It can be avoided by clearing the data before using other apps

Running other apps doesn't really do anything different than exiting the app.

Apparently it does. (*)

Note that "clearing the data" simply works because if there is no data there is nothing to render so Skia wont crash, it doesn't have anything to do with restoring the data itself as the style information is not saved over invocations of the app.

"style information is not saved" is another thing you are repeating for some reason. What difference would it make if it was saved?

updating Vespucci / rebooting the device.

Is Vespucci running when you are doing this? Because that is potentially equivalent to a forced close.

(*) Apparently it is, just like running other apps. Basically you have to either exit with back button or clear the data before doing anything else on your device. You can't for example take photos from Vespucci.

[simonpoole]

(*) Apparently it is, just like running other apps. Basically you have to either exit with back button or clear the data before doing anything else on your device. You can't for example take photos from Vespucci.

I would suggest checking for "memory management" apps and other things that could cause apps to be killed, because nothing of what you are suggesting is reproducible on the devices I have here that run pre-9 Android. Exiting the app regularly just invokes the normal Android activity lifecycle, just like Android will do if an app is paused and potentially later removed from memory.

[jidanni]

On ASUS, not only Vespucci dies, but it makes the entire ZenUI launcher restart, killing other apps too.

[AntonKhorev]

I would suggest checking for "memory management" apps and other things that could cause apps to be killed, because nothing of what you are suggesting is reproducible on the devices I have here that run pre-9 Android.

Run Vespucci, load an area with line patterns, reboot the device, run Vespucci again and you'll probably get a crash after "Loading data into memory" message. Did you try rebooting? Do memory management apps mess with rebooting? Or is rebooting one of those things that shouldn't be done?