[Apple Bug] iOS system regression in thread safety - must avoid decoding the same image on two threads

[ankorko]

I am facing a bug which I have a really hard time reproducing. I am using version 1.9.5 on an iPad 2. Sometimes when adding an ASTableView as a subview, cells will either not load at all or only parts of them will load. After that no rendering ever occurs. As you can see in the attached images there are many threads blocked on dispatch_semaphore_wait(__ASDisplayLayerConcurrentDisplaySemaphore, DISPATCH_TIME_FOREVER);

I have tried to reproduce this state by making the ASCellNodes really heavy (50 image subnodes), but still the occurrence of the freezing was random. The freezing never occurs later than (what seems to me to be) the very first rendering.

Any ideas on what the cause may be or at least how I can provide you with more info or a way to reproduce this?

[appleguy]

@ankorko I should be able to fix this with you. Something is pretty wrong here :).

Are you using SDWebImage, by chance?

Can you email me at asyncdisplaykit@gmail.com, and give me a contact to reach you via iMessage so we can debug?

[appleguy]

@ankorko Looking forward to a test app that thrashes the system by decoding the same asset in a lot of different image nodes. It should be relatively easy to create. Then we can develop and test a workaround for this Apple bug, and I can subsequently submit a Radar to them (and escalate it through channels at work).

[ankorko]

@appleguy Tried to modify the Kittens example to load 4-50 image nodes per ASCellNode with the same image assets I use (should it only occur with specific image types). No luck reproducing so far. Next step is to remove static assets loading from my project (or load UIImages that get reused a lot once in a singleton class) to verify that this is the cause. I will then try again to provide a sample project by simplifying mine. Maybe it's more complex than we initially thought.

[appleguy]

bt_all_result.txt

[appleguy]

time-profiler.trace.zip

[appleguy]

I'm implementing a workaround for this that should allow clients to not worry about this issue at the API / product layer, including removal of .displaysAsynchronously = NO setters.

[appleguy]

A stable workaround has been landed that should not have a measurably negative performance impact on any plausible use case I can imagine. Going to leave this open for a little while to see how testing goes.