Open ventr1x opened 2 years ago
ajwfrost
commented
2 years ago Hi @ventr1x - is that an ANR log? It's in the middle of garbage collection: I'd be very concerned if there was a crash due to this but an ANR I could understand.
Looks like there's some dynamic AS3 object being accessed/updating which is triggering a memory allocation at which point a bit of the incremental garbage collection marking is going on...
ventr1x
commented
2 years ago As title suggest this is an ANR, all crashes are random signal 11 that I can't debug.
So you are saying this ANR is our fault even though the only thing changed was an SDK update?
ajwfrost
commented
2 years ago Okay thanks - for signal 11 crashes, if you can share the call stacks with us (perhaps in a different bug report) we can see what's happening in those.
For this one, it's not that it's your fault, it's just that it seems to be that the runtime is going through normal operations so it's likely to just be some delays caused by garbage collection. The incremental garbage collection mechanism is meant to do small bits of "mark" work in the background (by which I mean, like this, at any point that a thread tries to do a memory allocation, the module will also take a small time-slice to do a bit of marking work). Once the marking has finished, there's then a "sweep" which happens which isn't incremental i.e. this can happen all at once, which can then be seen as glitches/small delays if there's a lot of garbage collection to actually carry out. Adobe had put in place a mechanism to try to force through the GC process at convenient times when users may not have noticed these delays (https://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system/System.html#pauseForGCIfCollectionImminent())
As ever, if you're able to get a Scout log of your application, it may be worth checking how the memory usage is going and seeing whether there are any significant-looking delays caused by memory sweep/collection in the normal operation prior to this sort of ANR happening.
But the challenge is that we don't for sure know what's causing the ANR because the system is still going, it's not stuck. We had some ANRs in the past that were clearly caused by deadlock or livelock where two threads were stuck waiting for each other, which is relatively easy to spot and to fix. This one is a lot less clear..
thanks
zabolott
commented
2 years ago 
After change SDK to 674 we received that
Input dispatching timed out (Waiting to send non-key event because the touched window has not finished processing certain input events that were delivered to it over 500.0ms ago. Wait queue length: 7. Wait queue head age: 21869.4ms.)
ilushaaa
commented
2 years ago Hi @zabolott, what AIR SDK version do you use for the stable release? Is anr rate below 0.47% threshold for it?
megajogos
commented
2 years ago We have the same issue here. But for Android 10 the ANR rate seens to be better:
We are using the SDK 33.1.1.674
It seems to be more or less the same error as #1252 But we are using .674. We are NOT using any audio or video from air but instead only distriqts ane (including mediation/ads).
We are at about 7% ANR and 5% crash (99% signal 11) rate, you can guess how happy our customers are about this.