Follow-up: iOS App Crashes Still Occurring After AIR SDK Update to 51.2.2.4

[Tuning3DT]

Hello,

I opened issue #3955 regarding iOS crashes in my app. Since there’s been no response to my recent comments there, I’m opening a new issue to follow up.

I updated to the latest AIR SDK 51.2.2.4 but unfortunately the crashes are still happening with no reduction in frequency. The crash reports are the same as before.

Could you please advise on next steps, or let me know if this is already being investigated? I’m attaching the latest crash logs here just in case.

com.3dtuning.Tuning3D_issue_3ceba855a8ad2d1af83655803dc13f70_crash_session_a38a8a70f9bc4590bed1c50d8bc27936_DNE_0_v2_stacktrace.txt

Thank you for your time.

[ajwfrost]

Hi - sorry, should have replied on that thread too, but these are all duplicates of part of #3804 that was meant to be fixed in AIR SDK 51.2.2.2, but the issue is still being seen. We have someone with some additional diagnostics in the runtime (which will be out in a general release at the end of this week) and if we can get an appropriate diagnostic report, we can hopefully work out why this is happening and how to protect against it.

thanks

[xxxVBxxx]

Hi @ajwfrost , is this AIR 51.2.2.5 the version where this issue was supposed to be fixed?

[ajwfrost]

@xxxVBxxx sadly not... it contains some extra diagnostic settings which might help us work out the issue, but we've already had feedback that the performance of the apps is impacted too heavily by these outputs (we're flushing reports to file so that we definitely have the data captured in case the process then crashes). So we are halfway through implementing an OSLog-based approach which will hopefully be more lightweight. There is a bit of urgency on this one though so we will perhaps publish the updated runtime here so that more people are able to try to get reproduction and analytics reports on it...

thanks

[premiumsB]

Hello @ajwfrost please inform me when the version is ready, so we can test its performance and check if it’s still slow to test AirDiagnostic. We tried on a second Mac and the APP is still really really slow.

[ajwfrost]

Hi - yes we're working on this, we have the logs now going into the system log mechanism which should mean less overhead! It's just a case of how to get them out (and how to work out whether the process had resulted in a crash or not, to avoid flooding ourselves with unnecessary information).

thanks

[premiumsB]

Hello @ajwfrost , I sent you an email if you can look at it please.

[ajwfrost]

Hi

Thanks for the logs @premiumsB ... those are showing that there is an issue and we can see why it's crashing - but the problem is, it shouldn't actually get to that point...

In the log file called 1760978965_4b48f35612d685f0_10518041.log we can see the problem:

CTURL: URL stream provider 0x111fcd580 constructor
CTURL: URL adapter 0x282d8b9c0 constructor with loader 0x111fcd580
CTURL: self 0x282d8b9c0 task 0x1056c2280 starting https...png
CTURL: self 0x111fcd580 starting asynchronous connection

so far so good...

But then we get it shutting down....

CTURL: self 0x111fcd580 releasing connection
CTURL: URL stream provider 0x111fcd580 destructor
CTURL: self 0x111fcd580 releasing connection
CTURL: self 0x282d8b9c0 clearing adapter 0x111fcd580
CTURL: URL adapter 0x282d8b9c0 destructor

This seems a little spurious i.e. I'm not sure what's triggering the 'release' - there's something that is trying to cancel the URL request, maybe something from ActionScript or maybe something from the OS?

But the problem is that we get another callback:

CTURL: self 0x282db1ce0 task 0x1056c2280 adapter 0x282d8b9c0 complete with error 0x2808cb240

BUT this 'adapter' value is something that has been deleted, so when we try to call a function on it, we get a crash.

Getting the adapter object should not actually be possible though, because when we see the first "releasing connection" log, we also remove the adapter from the map. So the very fact that we have a non-null adapter value in that final trace means that the NSDictionary.removeObjectForKey() method has not worked. Which we've not been able to reproduce when testing here...

I don't quite know how we can work around this. We can perhaps double-check after we try to remove it, and if we fail then we keep the object around, which may help... or we could add it to a separate map which could work around the failure.

Let me discuss internally and we'll see what may work best.

Appreciate all the log files though, thank you!

Andrew

[premiumsB]

Hello @ajwfrost Thank yuo for your research and no problem about the log files. We are waiting for your instructions. We hope you will find a solution soon.

[Faketa]

Any updates? We have crashes on the 51.2.2.6

[premiumsB]

@Faketa We are testing a few tweak with Andrew. I'm waiting an answer from him. What kind of crash do you have with 51.2.2.6 and which ANE do you use?