Android crashes #344
Comments
|
We can't change the AIR SDK version 29 of course, but we can see whether such an issue would be possible in our codebase and protect against it. The call stack shows that someone has clicked on a permission dialog and the result is coming back into the AIR runtime but then there's a failure when cleaning up the reference-counted objects that were created (probably during the ActionScript callback handler). From memory, I think we saw this sort of thing very early on when running a suite of tests where the permission dialog was on the screen still whilst the SWF file was then unloaded and the next one loaded in .. so I think we may already have put in a fix for this, but we can check.. (In case it helps, afaik no one has reported anything with AIR33 where we've seen that 'notify permission request result' callback in the call stack) |
|
@ajwfrost thank you so much! We have increased number of such a crash as well So these two crash types are quite different, aren't they? |
|
Interesting! So that other call stack you've put on there is also a 'Reap' operation on the zero count table, and it looks like an element on the table is no longer present .. The call stack in #304 might look similar at first sight but that is a crash when removing the last listener for a SensorEvent - there may be a possibility perhaps that both of these are caused by accidental clean-up of elements that have weak references where the element was already cleaned up.. we can do some digging here. It would be much easier if we could create a reproducible test case :-) thanks |
|
I'm getting similar crash reports on Android 9. These are 4 separate crashes. Potentially linked to audio playback. ` |
|
@crooksy88 can you please confirm what SDK build you were using here? |
|
33.1.1.633 |
|
And similar results with 33.1.1.686 This is definitely related to playing sound. If I use a native audio player (Distriqt AudioPlayer ANE) the app does to crash. The sound does load and play successfully. The crash will occur several seconds afterwards. |
|
Thanks for the test case! yes we had identified from the call stack that it's something to do with the sound object being shut down, and again probably a race condition when the sound is already closed prior to the time-out on the platform sound device. We'll try to get this more robust (but again, I'm really looking forward to when we get rid of all that code and have a different way to play simple sounds!) thanks |
|
@crooksy88 we've not been able to reproduce this weirdly .. using the test snippets that you've got and repeatedly running this, plus trying to automate it (but leaving time for the audio device to close on the timeout)... Is it possible for you to provide us with your app that's built using "apk-debug" so that we can check it reproduces here and then investigate? thanks |
|
OK that has been sent. |
|
@crooksy88 thanks for that - we can reproduce it when the app is run on its own (it's reporting itself as 33.1.1.633), but when we replace the libCore runtime library with the one from 33.1.1.686, we can no longer see the crashes happening... are you able to run it up on 686 and post a logcat output so we can see what may be happening here? thanks |
|
Yes I get the same results now under 686. No crashing with both debug and release builds. Not sure what I must have done when originally testing with 686 so sorry about that. We can leave this for now if yo are OK with that. Thanks for your help Andrew. |
|
Great thanks for confirming. Fingers crossed with this one.... |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem Description
We have many "signal 11 (SIGSEGV), code 2 (SEGV_ACCERR)" crashes reported to Google Play Console. Some of them have quite specific backtrace
AIR SDK: Adobe AIR 29 - I understand that here you basically support Harman SDK, and we've already started migration to Harman, but right now I need you help, I believe you can help us
Environment: Android (including 7+), quite usual devices from Samsung/Huawei/Xiaomi
Reproduce: No, about 1% of user sessions.
Known Workarounds: No
The text was updated successfully, but these errors were encountered: