Skip to content
This repository has been archived by the owner on Aug 14, 2019. It is now read-only.

Crash with race condition #368

Closed
virl opened this issue Jun 19, 2014 · 2 comments
Closed

Crash with race condition #368

virl opened this issue Jun 19, 2014 · 2 comments
Labels

Comments

@virl
Copy link

virl commented Jun 19, 2014

When receiving new message we add message to data source (remember that!) and call

[self finishReceivingMessage]

which calls

[self jsq_finishSendingOrReceivingMessage]

which in its first line sets

self.showTypingIndicator = NO;

which in its last line calls

[self scrollToBottomAnimated:YES];

which asks collectionView about number of items in section:

NSInteger items = [self.collectionView numberOfItemsInSection:0];

So in the end we have situation when datasource is modified, [self reloadData] is not yet called, but then we ask collectionView about its cell state.

That situation is 100% crash. It doesn't happen only because numberOfItemsInSection uses cached information and doesn't asks dataSource delegate directly..

Also that situation in some cases prevents proper scrolling, because [self scrollToBottomAnimated:] may not "know" about last row that was just added (because reloadData is not yet called).

To reproduce the crash, just add (and keep forever) following line as first line of scrollToBottomAnimated:

[self.collectionView performBatchUpdates:nil completion:nil];

It will effectively make any previous call to reloadData synchronous - it will wait for it to complete.

To fix the bug completely, in jsq_finishSendingOrReceivingMessage call reloadData before showTypingIndicator.

@jessesquires
Copy link
Owner

@virl - thanks for finding this! please submit a PR, it you want 👍

@virl
Copy link
Author

virl commented Jun 19, 2014

Ok, I will.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.