Klemens Böswirth
Klemens Böswirth
Any updates on this?
No, I did not manually symbolicate the stack trace. I'll try doing that. Is there a reason you publish the debug symbols separately instead of including them in the AAR...
Not sure whether this is the same crash, but we now managed to get a full symbolicated stack trace: ``` OS Version: Android 14 (UP1A.231005.007.A336BXXS9EXE2) Report Version: 104 Exception Type:...
I had another look at the logs for the crashes. It seems they happen exclusively after the map is no longer visible. Most crashes happen shortly (1 second or less)...
It seems the issue is not fully fixed, with version `11.1.0` we now get this stack trace for the segfault: ``` OS Version: Android 14 (UP1A.231005.007.G525FXXSCDXG2) Report Version: 104 Exception...
Is there any update on this issue? Do you need any additional crash data? We're now seeing this crash at a rate of about 5-10 per day.
We haven't been able to reproduce it in testing ourselves, so I can't provide a reproducer. We are using Jetpack Compose with our own wrapper similar to https://github.com/ramani-maps/ramani-maps (the library...
We tried switching to ramani-maps, but it doesn't currently support all the features we need. However, we have updated our lifecycle logic with a mix of code from ramani-maps and...
Seems that it indeed was an error in our lifecycle code. We've not seen any crashes on the new versions.
AFAICT in some situation we called `MapView.onDestory` twice. We relied on a `DisposableEffect` from compose, but used an extra key parameter which meant the `onDispose` callback and there for `MapView.onDestroy`...