Under-aligned exception instances on armeabi-v7a

Skip to first unread message

mic _

Apr 20, 2021, 4:38:01 AM4/20/21
to andro...@googlegroups.com
I'm seeing crashes in an armeabi-v7a library built with NDK r19c that I think might stem from this bug or something similar to it: https://bugs.llvm.org/show_bug.cgi?id=24604

The Google Play Developer Console doesn't show me the register values, but the crash reason is a SIGBUS (BUS_ADRALN) at a vst1.64 instruction which is trying to write two double-registers to a 128-bit aligned address. I'm guessing that's to clear the memory chunk that was returned by __cxa_allocate_exception.

Has this bug been fixed in the NDK? And if so, in which NDK release, and does the fix work regardless of which Android version you run on?  

Kollu Kishore Chowdary

Apr 20, 2021, 11:28:41 AM4/20/21
to andro...@googlegroups.com
Hi ,
If we keep minifield is true we using ndk app got crash,pls let me know.


You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/CAJwpw3Z7jxRDwzrOFMtbcT8D88gke5QJTpQGtsf3_2c%2BV-%2BpDw%40mail.gmail.com.


Apr 20, 2021, 1:02:38 PM4/20/21
to android-ndk
https://github.com/android/ndk/wiki/Changelog-r19 says that r19 had Clang r339409, and your bug claims to have been fixed in r296952.

always worth trying the latest version, though, since we're always going to say "please try again on a supported version". (plus i've just realized that the bug fix is in libc++, not clang, and tracking exactly what version of that you have is more tricky. so, yeah, "try the current NDK"...)


mic _

Apr 20, 2021, 2:18:41 PM4/20/21
to andro...@googlegroups.com
A complicating factor is that I've been unable to reproduce the crash myself so far, which together with the amount of crash reports suggests to me that the under-alignment is only happening sometimes.

Without being able to reproduce the issue or being able to verify statically that a newer NDK version solves the issue, I'd essentially have to use our users as test subjects, which I'd feel a bit uneasy about.

I suppose I could write a small test that just throws and catches exceptions in a loop indefinitely, in the hope that that will eventually trigger the crash, but that's not a waterproof strategy either.

Reply all
Reply to author
0 new messages