Crashes logged on Android Play Console

[carlos-mg89]

Hi,

I've been receiving a few errors at the Play Console that are quite hard for me to track and resolve due to the low amount of information that is being provided.

Most of the lines are useless. However I cannot manage to see if there's anything wrong from my code or not. Since there is no single mention to one of my classes.

Could anyone help me please? It's not like there are hundreds of errors, but there's a significant amount of them. Let's say around 5% of users (which in my app translates into 1-2 users per day) experience similar crashes.

This is the information I get:

Cluster: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR) libcarto_mobile_sdk.so

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 0 >>> com.walkaholic.hikeapp <<<

backtrace:
  #00  pc 00000000006f4064  /data/app/com.walkaholic.hikeapp-1/lib/arm64/libcarto_mobile_sdk.so
  #01  pc 00000000003f05b8  /data/app/com.walkaholic.hikeapp-1/lib/arm64/libcarto_mobile_sdk.so
  #02  pc 0000000000431770  /data/app/com.walkaholic.hikeapp-1/lib/arm64/libcarto_mobile_sdk.so
  #03  pc 00000000004322c8  /data/app/com.walkaholic.hikeapp-1/lib/arm64/libcarto_mobile_sdk.so
  #04  pc 000000000027355c  /data/app/com.walkaholic.hikeapp-1/lib/arm64/libcarto_mobile_sdk.so
  #05  pc 0000000000205ec0  /data/app/com.walkaholic.hikeapp-1/lib/arm64/libcarto_mobile_sdk.so
  #06  pc 00000000001fa084  /data/app/com.walkaholic.hikeapp-1/lib/arm64/libcarto_mobile_sdk.so
  #07  pc 00000000003ab6dc  /data/app/com.walkaholic.hikeapp-1/lib/arm64/libcarto_mobile_sdk.so
  #08  pc 00000000002868b4  /data/app/com.walkaholic.hikeapp-1/lib/arm64/libcarto_mobile_sdk.so
  #09  pc 0000000000285aac  /data/app/com.walkaholic.hikeapp-1/lib/arm64/libcarto_mobile_sdk.so (_ZNSt6thread5_ImplISt12_Bind_simpleIFSt7_Mem_fnIMN5carto20CancelableThreadPool10TaskWorkerEFvvEESt10shared_ptrIS5_EEEE6_M_runEv+40)
  #10  pc 00000000006f477c  /data/app/com.walkaholic.hikeapp-1/lib/arm64/libcarto_mobile_sdk.so
  #11  pc 0000000000067b24  /system/lib64/libc.so (_ZL15__pthread_startPv+52)
  #12  pc 000000000001edf0  /system/lib64/libc.so (__start_thread+16)

Another one here, but this one is a bit different:

Cluster: tgkill

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 0 >>> com.walkaholic.hikeapp <<<

backtrace:
  #00  pc 0000000000069d34  /system/lib64/libc.so (tgkill+8)
  #01  pc 000000000001de50  /system/lib64/libc.so (abort+88)
  #02  pc 0000000000025644  /system/lib64/libc.so (__libc_fatal+116)
  #03  pc 0000000000091204  /system/lib64/libc.so (ifree+812)
  #04  pc 0000000000091484  /system/lib64/libc.so (je_free+120)
  #05  pc 0000000000203530  /data/app/com.walkaholic.hikeapp-rt2BqR_V8V-JwF_q_3E9sA==/lib/arm64/libcarto_mobile_sdk.so
  #06  pc 0000000000203104  /data/app/com.walkaholic.hikeapp-rt2BqR_V8V-JwF_q_3E9sA==/lib/arm64/libcarto_mobile_sdk.so
  #07  pc 00000000001a0658  /data/app/com.walkaholic.hikeapp-rt2BqR_V8V-JwF_q_3E9sA==/lib/arm64/libcarto_mobile_sdk.so (_ZNSt14__shared_countILN9__gnu_cxx12_Lock_policyE2EED2Ev+68)
  #08  pc 00000000002868d4  /data/app/com.walkaholic.hikeapp-rt2BqR_V8V-JwF_q_3E9sA==/lib/arm64/libcarto_mobile_sdk.so
  #09  pc 0000000000285aac  /data/app/com.walkaholic.hikeapp-rt2BqR_V8V-JwF_q_3E9sA==/lib/arm64/libcarto_mobile_sdk.so (_ZNSt6thread5_ImplISt12_Bind_simpleIFSt7_Mem_fnIMN5carto20CancelableThreadPool10TaskWorkerEFvvEESt10shared_ptrIS5_EEEE6_M_runEv+40)
  #10  pc 00000000006f477c  /data/app/com.walkaholic.hikeapp-rt2BqR_V8V-JwF_q_3E9sA==/lib/arm64/libcarto_mobile_sdk.so
  #11  pc 00000000000666cc  /system/lib64/libc.so (_ZL15__pthread_startPv+36)
  #12  pc 000000000001f1e4  /system/lib64/libc.so (__start_thread+68)

[mtehver]

Thanks for the report. Have you reproduced any of the crashes yourself? Any hints what might have caused them? Both logs indicate a crash in a background native thread.

[carlos-mg89]

Sadly I've never been able to reproduce them myself. And it's troubling me. If at least I'd have an idea of on what layer or which element (Line, Marker or Point) were causing it, would be way easier to track. But at the moment I'm without any clue other than this backtrace.

Pretty much anything (perhaps everything I add to the mapview layers) that I draw is done on an async task, to prevent the user from waiting, and to allow me to continue the code execution.

[mtehver]

These two logs look quite different. The first one looks as something happened entirely within SDK. The second one looks as something in your MapListener or VectorElementListener triggered the issue and there is a memory corruption or duplicated 'free' operation. Just to be sure, you are not calling any 'delete' methods of the SDK classes in your code, right?

[carlos-mg89]

The methods I'm using that could be related with a 'delete' method of the Carto SDK are:

• LocalVectorDataSource::clear() => So I empty the DataSource and load new Points over the map
• MapView.layers.remove() => So I remove a layer and add a new one

Potentially, this could be related with the fact that while moving over the map, there could be a combination of both of the above mentioned methods. When I enter in a new region I do the folloging:

1. Get the Points I want to display
2. Clear the LocalVectorDataSource
3. Create a new one LocalVectorDataSource
4. Remove the Layer related with the previous the LocalVectorDataSource
5. Create a new Layer, with the new LocalVectorDataSource

I've just realized, that I could optimize this process, by changing the previous situation to:

1. Get the Points I want to display
2. Clear the LocalVectorDataSource

So basically I prevent the app from creating new LocalVectorDataSource and Layer objects. So I perform way less memory intense and cpu intense tasks. I only need to update the DataSource, by clearing the already existing Points, and adding the new ones. I have just tested it and the performance seems to have improved (although it was already great), and maybe this solves the issue.

Why am I doing this and I'm not loading all the Points at the beginning? Simply because there are a lot of Points (many many thousands of them). So I have reduced the situation where I get the Points I want to load from a bounding box (to be exact, the bounding box is 0.25 latitude wide and 0.25 longitude wide). This way, there are 'only' 5-10k points, and I've added as well a visibleZoomRange = MapRange(11f, 24f), so in the worst case there will be about 50 or 100 Points in a given moment displayed on the map. Which is much better for performace too.

My tests weren't that great if I added all the Points of a given region into my LocalVectorDataSource. Let's say, Catalonia or Aquitaine. Even with the MapRange in place.

[mtehver]

Thanks for the details, though without a reproducible test case it is very hard to track this. Using SDK methods from multiple threads is mostly safe. But there are a few exceptions - *Vector classes are NOT thread safe, thus using a MapPosVector from multiple threads may well cause such crashes.

Regarding the 'delete' method I asked about - most SDK classes contain a method called 'delete'. It is an API wrapping artifact that I would strongly suggest to ignore.

[carlos-mg89]

Alright, then since I'm using the LocalVectorDataSource class, I shouldn't be using it on my background task. And that would very well explain why I get those errors from time to time.

Any alternatives for loading many markers (right now I do it with the Point class, as I explained) over the map that I could update under certain circumstances (like changing from a bounding box to another)?

Or...perhaps, any way of detecting I clicked on a POI over the map? Right now, I'm just not displaying them, since I wanted the map to be interactive, so I'm showing a BottomSheetDialog after I click the marker. Right now, I assign in the Point metadata, the OpenStreetMap ID, so I display the information of the POI on the BottomSheetDialog. However, if it's possible for me to detect that a POI is clicked over the map, I wouldn't have to create Points.

[mtehver]

@carlos-mg89 One of our clients had somewhat similar issues a month ago. The issue turned out to be related to serializing SDK objects (MapPos in that case, to pass coordinates between activitites). This caused crashes during following GC cycles as SDK Java-side objects are basically small proxies to native state and cloning/serializing/deserializing them messes up reference counting. SDK 4.2 marks fields of proxy objects as 'transient' and such errors should be much easier to find.