Inability to get any useful info about Android crashes

[NB13]

Problem Description

Having crash reports in Google Play sometimes is useless without having unstripped SO libs, for instance

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 0 >>> com.belkatechnologies.fe <<<

backtrace:
  #00  pc 0000000000da1684  /data/app/com.belkatechnologies.fe-h04MfpQ1_S4j7yZy8IsJVQ==/lib/arm/libCore.so

All SO libs in Adobe AIR SDK (version 29, 31)- stripped. I mean
SDK_LOCATION/runtimes/air/android/device/Runtime.apk - file containing SO libs

lib/armeabi-v7a/libCore.so - ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=c47acd7bc8ce2ad463bb12e9fbf2d05de1993e30, stripped

https://tracker.adobe.com/#/view/AIR-4198717

Steps to Reproduce

Not applicable

[NB13]

@PrimaryFeather Daniel, I don't see any support from Adobe in this case, maybe you can give advice? I can not reproduce this type of crash, but have many of this in Google Play Console, even for high-end devices.

[PrimaryFeather]

I'm afraid I don't have any ideas how to get more information out of these reports - have you tried your luck in the Adobe AIR forums? (→ https://forums.adobe.com/community/air)

[Xgamefactory]

every one knows that adobe air forum is abandoned many years ago as adobe left support to unexperienced stuff from bangladesh ))

[ajwfrost]

Hi
Randomly came across this report and thought I'd comment .. I've got very extensive experience in debugging crashes like this!

Is this the only line you get of the backtrace? Normally I'd expect to see more entries in the list..
Some things to note:

1. if you got symbol information, it wouldn't help you as this crash is in Adobe's binary and you don't have source code access
2. AIR will be compiling all your ActionScript code to machine code and if the crash is in there, there is no symbol associated with it
3. the crucial thing to look for is whether there are any calls out to an ANE or similar within the call stack - this can be the source of bugs sometimes.

If this is just a crash within AIR itself, then only Adobe would be able to decipher it, and they would need the full call stack. Even with that, sometimes these are impossible to debug without being able to reproduce it.

Sorry - I know that doesn't really help!

[ghost]

Hi, @ajwfrost ! I would appreciate your help.

Here is all info about crash:
https://i.gyazo.com/6d938aae6ef29c5f5c0eb5bdee5b8b62.png

Answering your points

1. Yes, but sometimes symbol name can help. For instance we've managed to fix sounds ANRs only after we got symbols in ANR report - without any access to runtime code. Before this moment we had no idea about issue causing ANR at all
2. We can find "libCore.so" in report - I believe it's runtime code, not some form of my ActionScript code
3. One line only, no stacktrace :(

[ajwfrost]

Hi

Fair enough on the symbol names, yes I can see your point. libCore.so is the AIR library, I'm trying to remember though whether JIT code is flagged as being within this or not - perhaps you're right and this means it's not the dynamically allocated code memory that the JIT uses. However, the fact there's only one line of output can sometimes indicate that it was within the JIT because the return addresses sometimes don't get set up properly which stops the backtrace from appearing fully. The other time I've had this sort of thing was a buffer overrun where the writes to a stack variable resulted in part of the stack frame getting overwritten, the crash then happened at the end of the function. If it's that though, it's unlikely to be anything you can impact from the ActionScript level!

If it's reproducible then there's some hope.. otherwise yes, knowing the symbol name may give some clues but it's tricky..!

Good luck!

[ghost]

@ajwfrost hi! Maybe you have update on it in AIR 33?

[ajwfrost]

Hi - with AIR 33, yes we are creating the builds and therefore have the symbol files. We're not meant to give these out, but we definitely want people to report crashes when they happen! Even the top line of a call stack is useful, although having 3-4 lines is usually better..

We have found that crashes caused by JIT code don't appear as within the libCore.so range, but we can often identify them anyway. If there are reproducible issues caused by JIT, the first thing we do is update the JIT so that we get a symbol table generated on the fly! but that's fairly rare luckily..

So my suggestion is, if you're using AIR 33 and see a crash, always report it on here with as much of the call stack as possible! So far we know about one crash with 33.0.2.315 which is our latest release, again something to do with the audio code from first glance..

[Oldes]

@ajwfrost so you are able to find something useful even in these lines?

Asus ZenFone 5 Lite (ZC600KL) (ASUS_X017D_2), Android 9

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 0 >>> GP.demo <<<

backtrace:
  #00  pc 000000000057c3d4  /data/app/GP.demo-Rwxq-rBaa7rObggT26omMw==/lib/arm64/libCore.so
  #01  pc 0000000000619628  /data/app/GP.demo-Rwxq-rBaa7rObggT26omMw==/lib/arm64/libCore.so
  #02  pc 0000000000007a24  <anonymous>

[ajwfrost]

Yes if we know which release it was from.. I just had a look in case it was 33.0.2.315 but it doesn't appear to be (there's no branch statement at 0x619624 and no dereferencing of memory at 0x57c3d4)...

If it's in 33.0.2.288 though, this call stack would make sense, it's calling a function that iterates through all the movieclips and it looks like it's doing something like "getChildAt(x)" and then using the result without checking whether the result is null or not.

Normally the crash reports tell you what the error address is, so if it's something at/near zero this means it's likely a null pointer dereference and we can adjust the code accordingly. The danger is when this is apparently a valid address and we have to then try to work out what's gone wrong i.e. memory corruption or use-after-free or similar..

Is it repeatable? If so we could do you a test build with the extra null pointer check in it to see if it goes away... (although it would be good to first confirm that this is actually from 33.0.2.288!)

Thanks

[Oldes]

I don't think it is repeatable. It is one from 4 crash reports I see in the Play console. But if you can find it useful.. I can sand you more once our app submit with the recent sdk will not be rejected. We are fighting with metadata or something like that related to the new Google's stupid AI or who does the app aprovements.

[ajwfrost]

Okay thanks - yes, we can certainly stop that from crashing if it is just a null pointer dereference. Definitely send more whenever you find them, these sorts of reports often do point us somewhere where we can see what's happened and can just fix/protect against the issue, although sometimes it's a bit more complex e.g. the audio buffer access all looked fine from the code, but it was a race condition due to two threads accessing the same data at once..

[ghost]

Regarding initial ticket description, just to clarify - @ajwfrost SO libs packaging remains the same, but you are happy to help us with specific crashes, in separare issues with good description? So this issue can be closed.

[ajwfrost]

@belka-mobile-dev yes exactly