Random crash on Android 12 (hardened_malloc on GrapheneOS is crashing with "detected write after free") #4277
Comments
|
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? |
westnordost
added
the
feedback required
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 🤔 |
|
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? |
|
Do you have an email app on your phone? |
Yes I have K9-Mail on the phone |
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? ( |
I will try to do |
|
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 |
This is maybe related to the hardened_malloc in GrapheneOs... |
You can send to email at 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. |
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 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... 🤔
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? |
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. |
matkoniecz
changed the title
|
So the bug seems to be caused by StreetComplete itself: GrapheneOS/os-issue-tracker#1362 (comment) 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 |
Thanks a lot for the explanation :) |
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. |
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: 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. |
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. |
|
There are debugging tools like Valgrind which can likely detect the problem and provide a useful traceback. The hardened_malloc traceback isn't useful for debugging this. It just shows that it found a write-after-free, not what did it. |
|
But write-after-free of what? |
|
Ah, I understand now. So, the traceback is really useless for that matter. |
|
Thank you, @thestinger |
matkoniecz
changed the title
|
You could try using https://developer.android.com/ndk/guides/wrap-script with https://android.googlesource.com/platform/bionic/+/master/libc/malloc_debug/README.md. The free_track feature is similar to the hardened_malloc feature but is designed for debugging and should show where the free occurred which is almost always the code that's at fault because it likely used it after it freed it. |
|
So, as far as I know, there is only one library included in StreetComplete that uses JNI to access a native C++-library and that library is tangram-es. Which is a bit of a problem, because the development of tangram-es is effectively pretty much dead. I reported 5 individual crashes in February (tangrams/tangram-es#2315) and nothing was investigated or even provided debug symbols to get proper stack traces in the native code. I think it makes no sense to post a ticket for the suspicion of a memory allocation error over at tangram-es. An I am too little accustomed to C++ to just (fork and) look for the issues myself in that library. @thestinger thank you for the link. It reads though as if this is a tool for developers, i.e. adding this wrap.sh will only affect debug builds. This would necessitate me being able to reproduce it, though I haven't had the issue as reported yet (maybe because I am not using Android 12 yet). |
|
@westnordost It likely crashes outside GrapheneOS but only very rarely. GrapheneOS is detecting it as part of a set of security features to detect exploitable use-after-free vulnerabilities. Without the code for detecting it, the write after free would usually not be noticed unless something allocates memory before the write occurs in which case something being used would be overwritten. |
|
The crashes you're reporting are likely the same set of bugs. hardened_malloc is just detecting it and aborting instead of having an unexplained crash. hardened_malloc quarantines memory after it gets freed rather than allowing it to be used right away, and then checks to see if anything wrote to it after free. That's why it's a safe abort instead of some unexplained memory corruption crash. If you use malloc_debug, Valgrind or ASan, you can likely find the actual sources of these bugs. It probably is caused by that library. I see other assorted crashes reported. |
This comment was marked as off-topic.
This comment was marked as off-topic.
westnordost
removed
the
feedback required
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Actually, I will close this ticket, as it does not add any useful information: We know there are crashes in native code and we know where they come from (tangram-es, at least). Only after some/all of the native crashes caused by tangram-es are fixed it makes sense to revisit this - if then the issue would still be reproducible. |
|
Yes the crashes are probably due to tangram-es :/ |
|
Next release of GrapheneOS will have a per-app toggle for using 39-bit address space and Scudo (standard Android malloc) instead of 48-bit address space and hardened_malloc. If you get further reports about it you can tell users to enable that and it should work. |
|
Thanks for the info! |
|
Sorry for the necropost, but enabling Exploit protection compatibility mode for StreetComplete in settings "fixes" the crashing problem on GrapheneOS. |
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
The text was updated successfully, but these errors were encountered: