StreetComplete
StreetComplete copied to clipboard
streetcomplete
Random crash on Android 12 (hardened_malloc on GrapheneOS is crashing with "detected write after free")
When navigating the map, the app crashes : it happened while on motorway and also while navigating on the map "far" from my current position (a few kilometers)
How to Reproduce Currently I don't know how to reproduce.
Expected Behavior Should not crash.
Versions affected Android 12 StreetComplete 45.1 from F-Droid
I will wait for 45.2 to reach F-Droid and give you my feedback if it resolves the issue :)
Did you send a crash report when the app asked you to?
The app did not asked me to, I just restarted the app and nothing showed up! Just also tested 45.2 but the crash still happens, and this time it's really regular :thinking:
I can't think of any situation where the app would not ask you to send a crash report after it crashed if you got the app from F-Droid. It does not ask if you got the app from Google Play or if it is a development build. Maybe the app is "regularly" killed by the system (For whatever reason), so it does not count as a crash?
Maybe the app is "regularly" killed by the system (For whatever reason), so it does not count as a crash?
The battery setting for this app was set to "Optimised", I just set it to "Without restrictions" and will try to see if it resolves the crash issue
The battery setting for this app was set to "Optimised", I just set it to "Without restrictions" and will try to see if it resolves the crash issue
Still crashing, so it was not the issue here :)
So 🤷 I don't know. Apparently, StreetComplete does not get notified that there is a crash, which is why it does not ask to send a crash report. It sounds like the crash happens outside of the app, maybe?
Do you have access to your system log? (adb logcat) Maybe the system log will reveal what is going wrong.
Do you have access to your system log? (
adb logcat) Maybe the system log will reveal what is going wrong.
I will try to do adb logcat as son as possible :)
I managed to record the crash with adb logcat :) Which part is important for you (because it's pretty long, and haven't looked at it if there is any personnal data.
The crash itself should not be too long. Everything of the strack trace would be nice, but what happened immediately before might be interesting too
08-08 16:27:31.778 22772 22805 F hardened_malloc: fatal allocator error: detected write after free
08-08 16:27:31.778 22772 22805 F libc : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 22805 (DefaultDispatch), pid 22772 (.streetcomplete)
This is maybe related to the hardened_malloc in GrapheneOs...
haven't looked at it if there is any personnal data.
You can send to email at https://github.com/streetcomplete/StreetComplete/blob/e34f3b5163d4c443c6436fddb531c1116c0529a7/app/src/main/java/de/westnordost/streetcomplete/ApplicationModule.kt#L17 if you prefer to not make it public
I think that the most private info is location, anyway revealed by your mapping
haven't looked at it if there is any personnal data.
You can send to email at
https://github.com/streetcomplete/StreetComplete/blob/e34f3b5163d4c443c6436fddb531c1116c0529a7/app/src/main/java/de/westnordost/streetcomplete/ApplicationModule.kt#L17 if you prefer to not make it public
I think that the most private info is location, anyway revealed by your mapping
From what I understand the 2 lines I sent are a good start, looks to be a security feature implemented in hardened_malloc, securing for memory allocation errors...
But it is not a stack trace. Is there no stack trace? That error just means that somewhere in native code, a process wasn't able to assign memory.
But it is not a stack trace. Is there no stack trace? That error just means that somewhere in native code, a process wasn't able to assign memory.
08-08 16:27:32.440 22878 22878 F DEBUG : pid: 22772, tid: 22805, name: DefaultDispatch >>> de.westnordost.streetcomplete <<<
08-08 16:27:32.440 22878 22878 F DEBUG : uid: 10135
08-08 16:27:32.440 22878 22878 F DEBUG : signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
08-08 16:27:32.440 22878 22878 F DEBUG : x0 0000000000000000 x1 0000000000005915 x2 0000000000000006 x3 0000ca63833baa20
08-08 16:27:32.440 22878 22878 F DEBUG : x4 1f63647362647364 x5 1f63647362647364 x6 1f63647362647364 x7 7f7f7f7f7f7f7f7f
08-08 16:27:32.440 22878 22878 F DEBUG : x8 00000000000000f0 x9 0000ca96b3125a10 x10 0000000000000000 x11 ffffff80fffffbdf
08-08 16:27:32.440 22878 22878 F DEBUG : x12 0000000000000001 x13 0000000100000000 x14 0000ca63833ba630 x15 0000000000000000
08-08 16:27:32.440 22878 22878 F DEBUG : x16 0000ca96b31c0158 x17 0000ca96b319d470 x18 0000ca6382728000 x19 00000000000058f4
08-08 16:27:32.440 22878 22878 F DEBUG : x20 0000000000005915 x21 00000000ffffffff x22 0000ca6adcf765b0 x23 0000ca9534dd3200
08-08 16:27:32.440 22878 22878 F DEBUG : x24 b400ca67ebe19380 x25 0000000000000070 x26 0000000000000007 x27 0000ca951f6a0000
08-08 16:27:32.440 22878 22878 F DEBUG : x28 0000ca951f7a1550 x29 0000ca63833baaa0
08-08 16:27:32.440 22878 22878 F DEBUG : lr 0000ca96b3150288 sp 0000ca63833baa00 pc 0000ca96b31502b8 pst 0000000000000000
08-08 16:27:32.440 22878 22878 F DEBUG : backtrace:
08-08 16:27:32.440 22878 22878 F DEBUG : #00 pc 000000000004c2b8 /apex/com.android.runtime/lib64/bionic/libc.so (abort+168) (BuildId: 761d634420410980165d18a838ce8c70)
08-08 16:27:32.440 22878 22878 F DEBUG : #01 pc 0000000000043394 /apex/com.android.runtime/lib64/bionic/libc.so (fatal_error+112) (BuildId: 761d634420410980165d18a838ce8c70)
08-08 16:27:32.440 22878 22878 F DEBUG : #02 pc 00000000000405bc /apex/com.android.runtime/lib64/bionic/libc.so (allocate+2116) (BuildId: 761d634420410980165d18a838ce8c70)
08-08 16:27:32.440 22878 22878 F DEBUG : #03 pc 000000000003bc30 /apex/com.android.runtime/lib64/bionic/libc.so (malloc+36) (BuildId: 761d634420410980165d18a838ce8c70)
08-08 16:27:32.440 22878 22878 F DEBUG : #04 pc 000000000004cb8c /system/lib64/libc++.so (operator new(unsigned long)+24) (BuildId: 8a3045534e859293b5fb63562d4811eb)
08-08 16:27:32.440 22878 22878 F DEBUG : #05 pc 00000000000979a8 /system/lib64/libc++.so (std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__grow_by(unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, unsigned long)+152) (BuildId: 8a3045534e859293b5fb63562d4811eb)
08-08 16:27:32.440 22878 22878 F DEBUG : #06 pc 0000000000097a88 /system/lib64/libc++.so (std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::push_back(char)+100) (BuildId: 8a3045534e859293b5fb63562d4811eb)
08-08 16:27:32.440 22878 22878 F DEBUG : #07 pc 000000000028c818 /apex/com.android.art/lib64/libart.so (std::__1::basic_stringbuf<char, std::__1::char_traits<char>, std::__1::allocator<char> >::overflow(int)+108) (BuildId: 82b8f687190ca282ccd47876ca6c57b9)
08-08 16:27:32.440 22878 22878 F DEBUG : #08 pc 000000000005ae0c /system/lib64/libc++.so (std::__1::basic_streambuf<char, std::__1::char_traits<char> >::xsputn(char const*, long)+140) (BuildId: 8a3045534e859293b5fb63562d4811eb)
08-08 16:27:32.440 22878 22878 F DEBUG : #09 pc 000000000027c4d8 /apex/com.android.art/lib64/libart.so (std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> > std::__1::__pad_and_output<char, std::__1::char_traits<char> >(std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> >, char const*, char const*, char const*, std::__1::ios_base&, char)+328) (BuildId: 82b8f687190ca282ccd47876ca6c57b9)
08-08 16:27:32.440 22878 22878 F DEBUG : #10 pc 000000000027c330 /apex/com.android.art/lib64/libart.so (std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::__put_character_sequence<char, std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char const*, unsigned long)+212) (BuildId: 82b8f687190ca282ccd47876ca6c57b9)
08-08 16:27:32.441 22878 22878 F DEBUG : #11 pc 00000000002e98d8 /apex/com.android.art/lib64/libart.so (art::AddReferrerLocation(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, art::ObjPtr<art::mirror::Class>)+108) (BuildId: 82b8f687190ca282ccd47876ca6c57b9)
08-08 16:27:32.441 22878 22878 F DEBUG : #12 pc 00000000002e4a38 /apex/com.android.art/lib64/libart.so (art::ThrowException(char const*, art::ObjPtr<art::mirror::Class>, char const*, std::__va_list*) (.llvm.16620363683444992276)+388) (BuildId: 82b8f687190ca282ccd47876ca6c57b9)
08-08 16:27:32.441 22878 22878 F DEBUG : #13 pc 00000000002e785c /apex/com.android.art/lib64/libart.so (art::ThrowNoSuchFieldException(art::ObjPtr<art::mirror::Class>, std::__1::basic_string_view<char, std::__1::char_traits<char> >)+340) (BuildId: 82b8f687190ca282ccd47876ca6c57b9)
08-08 16:27:32.441 22878 22878 F DEBUG : #14 pc 0000000000570188 /apex/com.android.art/lib64/libart.so (art::Class_getDeclaredField(_JNIEnv*, _jobject*, _jstring*)+2124) (BuildId: 82b8f687190ca282ccd47876ca6c57b9)
08-08 16:27:32.441 22878 22878 F DEBUG : #15 pc 00000000000b1810 /apex/com.android.art/javalib/arm64/boot.oat (art_jni_trampoline+112) (BuildId: 165623f6d01b95c1fa9ab0d0ac3f13f5e28dc768)
08-08 16:27:32.441 22878 22878 F DEBUG : #16 pc 00000000008b0cf8 /data/app/~~lkH7g7HFDf_wipQGQqv1sg==/de.westnordost.streetcomplete-E8xE1EGkgLXi_h-EThCPkw==/oat/arm64/base.odex (kotlinx.serialization.internal.PlatformKt.companionOrNull+72)
08-08 16:27:32.441 22878 22878 F DEBUG : #17 pc 00000000008b2cc8 /data/app/~~lkH7g7HFDf_wipQGQqv1sg==/de.westnordost.streetcomplete-E8xE1EGkgLXi_h-EThCPkw==/oat/arm64/base.odex (kotlinx.serialization.internal.PlatformKt.invokeSerializerOnCompanion+56)
08-08 16:27:32.441 22878 22878 F DEBUG : #18 pc 00000000008b11c8 /data/app/~~lkH7g7HFDf_wipQGQqv1sg==/de.westnordost.streetcomplete-E8xE1EGkgLXi_h-EThCPkw==/oat/arm64/base.odex (kotlinx.serialization.internal.PlatformKt.constructSerializerForGivenTypeArgs+440)
08-08 16:27:32.441 22878 22878 F DEBUG : #19 pc 00000000008aa488 /data/app/~~lkH7g7HFDf_wipQGQqv1sg==/de.westnordost.streetcomplete-E8xE1EGkgLXi_h-EThCPkw==/oat/arm64/base.odex (kotlinx.serialization.SerializersKt__SerializersKt.serializerByKTypeImpl$SerializersKt__SerializersKt+1304)
08-08 16:27:32.441 22878 22878 F DEBUG : #20 pc 00000000008a75c8 /data/app/~~lkH7g7HFDf_wipQGQqv1sg==/de.westnordost.streetcomplete-E8xE1EGkgLXi_h-EThCPkw==/oat/arm64/base.odex (kotlinx.serialization.SerializersKt__SerializersKt.builtinSerializer$SerializersKt__SerializersKt+1128)
08-08 16:27:32.441 22878 22878 F DEBUG : #21 pc 00000000008aa2a0 /data/app/~~lkH7g7HFDf_wipQGQqv1sg==/de.westnordost.streetcomplete-E8xE1EGkgLXi_h-EThCPkw==/oat/arm64/base.odex (kotlinx.serialization.SerializersKt__SerializersKt.serializerByKTypeImpl$SerializersKt__SerializersKt+816)
08-08 16:27:32.441 22878 22878 F DEBUG : #22 pc 0000000000712b74 /data/app/~~lkH7g7HFDf_wipQGQqv1sg==/de.westnordost.streetcomplete-E8xE1EGkgLXi_h-EThCPkw==/oat/arm64/base.odex (de.westnordost.streetcomplete.data.osm.mapdata.NodeDaoKt.toNode+1332)
08-08 16:27:32.441 22878 22878 F DEBUG : #23 pc 0000000000ed09b8 /data/app/~~lkH7g7HFDf_wipQGQqv1sg==/de.westnordost.streetcomplete-E8xE1EGkgLXi_h-EThCPkw==/oat/arm64/base.odex (de.westnordost.streetcomplete.data.osm.mapdata.NodeDao$getAll$2.invoke+216)
08-08 16:27:32.441 22878 22878 F DEBUG : #24 pc 0000000000ba56e0 /data/app/~~lkH7g7HFDf_wipQGQqv1sg==/de.westnordost.streetcomplete-E8xE1EGkgLXi_h-EThCPkw==/oat/arm64/base.odex (de.westnordost.streetcomplete.data.AndroidDatabase.query+912)
08-08 16:27:32.441 22878 22878 F DEBUG : #25 pc 000000000069ea58 /data/app/~~lkH7g7HFDf_wipQGQqv1sg==/de.westnordost.streetcomplete-E8xE1EGkgLXi_h-EThCPkw==/oat/arm64/base.odex (de.westnordost.streetcomplete.data.Database$DefaultImpls.query$default+264)
08-08 16:27:32.441 22878 22878 F DEBUG : #26 pc 00000000006fb4bc /data/app/~~lkH7g7HFDf_wipQGQqv1sg==/de.westnordost.streetcomplete-E8xE1EGkgLXi_h-EThCPkw==/oat/arm64/base.odex (de.westnordost.streetcomplete.data.osm.mapdata.ElementDao.getAll+380)
08-08 16:27:32.441 22878 22878 F DEBUG : #27 pc 00000000007085b8 /data/app/~~lkH7g7HFDf_wipQGQqv1sg==/de.westnordost.streetcomplete-E8xE1EGkgLXi_h-EThCPkw==/oat/arm64/base.odex (de.westnordost.streetcomplete.data.osm.mapdata.MapDataController.getMapDataWithGeometry+200)
08-08 16:27:32.441 22878 22878 F DEBUG : #28 pc 0000000000bc1144 /data/app/~~lkH7g7HFDf_wipQGQqv1sg==/de.westnordost.streetcomplete-E8xE1EGkgLXi_h-EThCPkw==/oat/arm64/base.odex (de.westnordost.streetcomplete.data.osm.edits.MapDataWithEditsSource.getMapDataWithGeometry+180)
08-08 16:27:32.441 22878 22878 F DEBUG : #29 pc 00000000011e349c /data/app/~~lkH7g7HFDf_wipQGQqv1sg==/de.westnordost.streetcomplete-E8xE1EGkgLXi_h-EThCPkw==/oat/arm64/base.odex (de.westnordost.streetcomplete.screens.main.map.StyleableOverlayManager$onNewTilesRect$1$mapData$1.invokeSuspend+284)
08-08 16:27:32.441 22878 22878 F DEBUG : #30 pc 0000000000cc1ae4 /data/app/~~lkH7g7HFDf_wipQGQqv1sg==/de.westnordost.streetcomplete-E8xE1EGkgLXi_h-EThCPkw==/oat/arm64/base.odex (kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith+292)
08-08 16:27:32.441 22878 22878 F DEBUG : #31 pc 0000000000cca7d0 /data/app/~~lkH7g7HFDf_wipQGQqv1sg==/de.westnordost.streetcomplete-E8xE1EGkgLXi_h-EThCPkw==/oat/arm64/base.odex (kotlinx.coroutines.DispatchedTask.run+1824)
08-08 16:27:32.441 22878 22878 F DEBUG : #32 pc 00000000012426dc /data/app/~~lkH7g7HFDf_wipQGQqv1sg==/de.westnordost.streetcomplete-E8xE1EGkgLXi_h-EThCPkw==/oat/arm64/base.odex (kotlinx.coroutines.internal.LimitedDispatcher.run+764)
08-08 16:27:32.441 22878 22878 F DEBUG : #33 pc 0000000000cd5e8c /data/app/~~lkH7g7HFDf_wipQGQqv1sg==/de.westnordost.streetcomplete-E8xE1EGkgLXi_h-EThCPkw==/oat/arm64/base.odex (kotlinx.coroutines.scheduling.TaskImpl.run+76)
08-08 16:27:32.441 22878 22878 F DEBUG : #34 pc 00000000008a1984 /data/app/~~lkH7g7HFDf_wipQGQqv1sg==/de.westnordost.streetcomplete-E8xE1EGkgLXi_h-EThCPkw==/oat/arm64/base.odex (kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely+68)
08-08 16:27:32.441 22878 22878 F DEBUG : #35 pc 000000000089c8a8 /data/app/~~lkH7g7HFDf_wipQGQqv1sg==/de.westnordost.streetcomplete-E8xE1EGkgLXi_h-EThCPkw==/oat/arm64/base.odex (kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker+1128)
08-08 16:27:32.441 22878 22878 F DEBUG : #36 pc 000000000089e0e8 /data/app/~~lkH7g7HFDf_wipQGQqv1sg==/de.westnordost.streetcomplete-E8xE1EGkgLXi_h-EThCPkw==/oat/arm64/base.odex (kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run+40)
08-08 16:27:32.441 22878 22878 F DEBUG : #37 pc 0000000000218964 /apex/com.android.art/lib64/libart.so (art_quick_invoke_stub+548) (BuildId: 82b8f687190ca282ccd47876ca6c57b9)
08-08 16:27:32.441 22878 22878 F DEBUG : #38 pc 0000000000284080 /apex/com.android.art/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+184) (BuildId: 82b8f687190ca282ccd47876ca6c57b9)
08-08 16:27:32.441 22878 22878 F DEBUG : #39 pc 000000000061776c /apex/com.android.art/lib64/libart.so (art::JValue art::InvokeVirtualOrInterfaceWithJValues<art::ArtMethod*>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, art::ArtMethod*, jvalue const*)+460) (BuildId: 82b8f687190ca282ccd47876ca6c57b9)
08-08 16:27:32.441 22878 22878 F DEBUG : #40 pc 0000000000665c88 /apex/com.android.art/lib64/libart.so (art::Thread::CreateCallback(void*)+1164) (BuildId: 82b8f687190ca282ccd47876ca6c57b9)
08-08 16:27:32.441 22878 22878 F DEBUG : #41 pc 00000000000ae080 /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+204) (BuildId: 761d634420410980165d18a838ce8c70)
08-08 16:27:32.441 22878 22878 F DEBUG : #42 pc 000000000004da70 /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: 761d634420410980165d18a838ce8c70)
Is this what you are looking for?
Yes, thank you! Looks on first glance like an issue outside of StreetComplete though. The last line of code executed is
https://github.com/streetcomplete/StreetComplete/blob/c2def4404b72c6edb855dd9fb7a0596d69674056/app/src/main/java/de/westnordost/streetcomplete/data/osm/mapdata/NodeDao.kt#L97
Or written in another way, more clearly:
Json.decodeFromString<Map<String, String>>(aString)
Then, it is off to the kotlinx-serialization library (that converts JSON strings to Java objects). I doubt though that the issue is in kotlinx-serialization. kotlinx-serialization does not have native code (for the code that runs on a JVM). Code that runs in the JVM cannot trigger any error in memory allocation.
To me, it looks like the error is in ART itself, which is a component of your Android system (The Android system's Java Virtual Machine on which all apps are executed). This would also explain why StreetComplete does not notice that it crashed. The container in which StreetComplete was executed crashed.
I suggest to report this to GrapheneOS developers or maybe first look if an update is available or the problem is already known.
Thanks a lot for your explanation! But this is strange as it only happens on StreetComplete... :thinking:
I suggest to report this to GrapheneOS developers or maybe first look if an update is available or the problem is already known.
I already have the latest version installed, so I might open an issue there. So the affected component is the probably the ART of GrapheneOS?
But this is strange as it only happens on StreetComplete...
Maybe it is more noticeable with SC and some other people complain about notification sometimes not working or about not getting notified about emails? Or something else just crashes and you have not investigated it.
Also, SC serializes/de-serializes more and more complex data than many apps.
So the bug seems to be caused by StreetComplete itself: https://github.com/GrapheneOS/os-issue-tracker/issues/1362#issuecomment-1208269870
It is a "write after free bug" in the app, so something that needs to be fixed on the side of StreetComplete if I understood correctly :)
This is a write-after-free or buffer overflow bug in your app. When an allocation is freed with hardened_malloc, the memory is zeroed. When allocations are created, hardened_malloc checks that the data is still zero to detect writes which occurred while the allocation was freed (write-after-free). It could be because of a use-after-free bug (most likely) or a buffer overflow from a nearby allocation. The traceback for the abort shows where the error was detected on allocation, not where it was freed. You need to use ASan and other tooling like that to debug the issue. It's almost certainly a memory corruption bug in the app code or library code used by it.
Android applications run in ART, this is a JVM environment. Code that runs in the JVM cannot cause a memory (corruption) error.
Is it possible that kotlinx.serialization.internal.PlatformKt has some buggy native code that crashes here?
This is a write-after-free or buffer overflow bug in your app. When an allocation is freed with hardened_malloc, the memory is zeroed. When allocations are created, hardened_malloc checks that the data is still zero to detect writes which occurred while the allocation was freed (write-after-free). It could be because of a use-after-free bug (most likely) or a buffer overflow from a nearby allocation. The traceback for the abort shows where the error was detected on allocation, not where it was freed. You need to use ASan and other tooling like that to debug the issue. It's almost certainly a memory corruption bug in the app code or library code used by it.
Thanks a lot for the explanation :)
Is it possible that kotlinx.serialization.internal.PlatformKt has some buggy native code that crashes here?
Possible. One think I did not mention in the comment I posted 2 minutes ago is that it is possible to add native code to Java libraries (via JNI), so any Java library could theoretically have some native components. StreetComplete does not, but perhaps kotlinx.serialization does.
Android applications run in ART, this is a JVM environment. Code that runs in the JVM cannot cause a memory (corruption) error.
Java has an unsafe module and JNI for using C and C++ libraries. There are plenty of memory corruption bugs in Android apps via their C and C++ dependencies.
@matkoniecz @thestinger doesn't look like the code in PlatformKt is accessing JNI/native code though:
https://github.com/Kotlin/kotlinx.serialization/blob/16a85df254f4f1e317554eb61ee1fbe914800aa4/core/jvmMain/src/kotlinx/serialization/internal/Platform.kt#L118-L125
Just some reflection.
The traceback shows what triggered the allocation where the write after free was detected. It's not what freed the memory and what wrote to the memory after it was freed. There's no particular reason to assume it has anything to do with that library.
This is a write-after-free or buffer overflow bug in your app. When an allocation is freed with hardened_malloc, the memory is zeroed. When allocations are created, hardened_malloc checks that the data is still zero to detect writes which occurred while the allocation was freed (write-after-free). It could be because of a use-after-free bug (most likely) or a buffer overflow from a nearby allocation. The traceback for the abort shows where the error was detected on allocation, not where it was freed. You need to use ASan and other tooling like that to debug the issue. It's almost certainly a memory corruption bug in the app code or library code used by it.
Look at what I wrote above. The traceback is where memory was allocated where hardened_malloc found that something had written to memory that wasn't allocated. What likely happened is that something freed an allocation and then wrote to it after free. The traceback showing where it was detecting doesn't have a particular reason to be related. It's the same kind of thing as detecting that something overwrote a random canary. The place that detects it is just where the check was run, not what caused the memory corruption.