Signal-iOS/Signal/src
george-signal 98acf9687a
Fix a crash in stories tableview. (#4692)
Commit 04737ff044
attempted to fix an assertion in
StoriesViewController due to UITableView
complaining about inconsistent state. The issue
continues to happen. This diff fixes it once and
for all (I hope!).

The scenario that caused a crash prior to
04737ff044 was:

  Initially:
  models = [a,b,c]

  Database changes to [a,b]

  reloadStories (loading queue)
      newModels = [a,b]
      schedule block to run on main queue

  Database changes to [x, b]

  updateStories (loading queue)
      captures self.models, value is [a,b,c] // cue ominous music
      load from database
      newModels = [x,b]
      schedule block to run on main queue; will delete c and change a to x

  reloadStories.block runs on main queue
      self.models=newModels, value is [a,b]
      tableView.reloadData()  // UITableView thinks c is deleted

  updateStories.block runs on main queue
      self.models=newModels, value is [x,b]
      tableView.beginUpdates()
      tableView.delete(index: 2)  // crashes because c was already deleted

Post-04737ff the following scenario causes a
crash:

  Initially:
  models = [a,b,c]

  Database changes to [a,b]

  updateStories (loading queue)
      load from database
      models.set([a,b])
      schedule block to run on main queue which will delete c

  iOS gets a wild hair and decides to call some
  UITableViewDataSource methods.

  tableView(_, numberOfRowsInSection:)
      return [a,b].count  // Now UIKit thinks c is gone

  updateStories.block runs on main queue
      tableView.beginUpdates()
      tableView.delete(index: 2)  // crashes because 2 is out of bounds vs number of rows

This commit fixes the problem by ensuring the
read-modify-write that happens in updateStories
never reads older data than what UITableView
has been told about and also that updates to the
model are properly synchronized with
beginUpdates()...endUpdates().

Here's how to think about it: the database goes
through a series of changes. Call them v1, v2,
..., vN.

The loading queue will see each in turn. For each,
it will enqueue a corresponding block on the main
queue to update `model` and tell UITableView about
it.

From the POV of the main queue, each update occurs
in the scope of a UITableView update.

From the POV of the loading queue, each update
reads from exactly the preceding version (from
`trueModels`) and writes to exactly the next
version of `trueModels`.

Therefore, there are no data races.
2022-08-08 10:34:39 -07:00
..
Calls Be more deliberate about starting/ending orientation notifications 2022-08-05 08:11:38 -05:00
environment Prompt for diagnostics if db corruption happens 2022-07-27 11:57:16 -05:00
Experience Upgrades Fix violations of SwiftLint's attributes rule 2022-05-14 09:07:42 -05:00
Jobs Initial story sending support 2022-06-10 22:28:03 -04:00
Models Move dependencies needed for private story creation to SignalUI 2022-07-15 15:05:03 -07:00
UserInterface Fix wrong localization key 2022-05-04 09:54:09 -05:00
util Remove unnecessary NotificationCenter.removeObserver calls 2022-08-02 17:43:52 -07:00
ViewControllers Fix a crash in stories tableview. (#4692) 2022-08-08 10:34:39 -07:00
views Propagate ThreadAssociatedData audioPlaybackRate down to CVComponentAudioAttachment 2022-08-04 15:53:11 -07:00
AppDelegate.h Show the launch failure screen if the last app launch crashed 2022-04-22 09:55:59 -07:00
AppDelegate.m Remove "Linked Devices" item on linked devices 2022-08-04 08:39:59 -05:00
AppDelegate.swift Move checkSomeDiskSpaceAvailable to Swift 2022-07-27 12:17:00 -05:00
Signal-Bridging-Header.h Remove app screenshot generation code 2022-05-04 12:32:20 -05:00