0

I'm getting following crash. Can't figure out what to look for. Is it related to qos?

Crashed: com.apple.root.utility-qos EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000020 Crashed: com.apple.root.utility-qos

enter image description here

If it's related to qos then I've only following code in my project. Can this code be causing this crash? If this is the culprit then how to fix it?

DispatchQueue.global(qos: .userInitiated).async { [weak self] in
    guard let _ = self else {
        return
    }
    updateStatusToOnline()
}
Daniel Muñoz
  • 547
  • 1
  • 7
  • 23
Oliver
  • 13
  • 1
  • 6
  • what is `updateStatusToOnline`? is it a block (`var updateStatusToOnline = { ... }`) or is it a function (`func updateStatusToOnline() { ... }`) – Michael Aug 21 '19 at 18:15
  • 1
    This may help: https://stackoverflow.com/questions/27948618/consistent-dispatch-queue-com-apple-root-default-qos-overcommit-crash substituting utility for default. – Michael Salmon Aug 21 '19 at 18:18
  • It's a function in which I'm fetching API to update status in the backend on my server. – Oliver Aug 21 '19 at 18:18
  • if updateStatusToOnline is a normal function (and not a closure), the snippet of code you've shown can only crash if something inside updateStatusToOnline() crashes. – Michael Aug 21 '19 at 18:20
  • @Michael Salmon Tx I'll change qos to .background and will check. – Oliver Aug 21 '19 at 18:21
  • what happens if you change `guard let _ = self` to `guard let strongSelf = self`? (I know, there will be a compiler warning if you do this, but we can find a better fix later.) – Michael Aug 21 '19 at 18:26
  • If you can fix it by changing `.userInitiated` to `.background`, you have just found a race condition. It's good to know, but you should not use it as a fix in production, because it may break with the next iOS minor version upgrade. The QOS parameter should be the real QOS that you intend to use: if the action was user-initiated then the block should run in the `.userInitiated` queue or the app may seem unresponsive. If it is a race condition you can try the thread sanitizer. If this doesn't help, you can try the undefined behaviour sanitizer. – Michael Aug 21 '19 at 18:37
  • @Michael It's heavy for me, too much to get my head around. It's not user initiated. I want fetch API in the background without blocking UI or user. So shall I use .background for live app? – Oliver Aug 21 '19 at 18:41
  • @Oliver: both queues are background queues, which just means that they don't block the main queue. `.userInitiated` is a high-priority-queue, because the reasoning is "if the user initiated an action (e.g. by tapping on a button, hence `.userInitiated`), then he/she might notice if the response from the system takes 100ms or if it takes 700ms". `.background` is a low-priority queue for stuff where it doesn't matter if the system does this task now or a bit later, because the user wouldn't notice anyways. – Michael Aug 21 '19 at 19:14
  • does `updateStatusToOnline` update the user interface? if yes, it crashes because you are accessing the GUI from a background thread. You should just replace your code with `updateStatusToOnline()` then. – Michael Aug 21 '19 at 19:21
  • or `DispatchQueue.main.async { updateStatusToOnline(); }` if you are already on a background queue. – Michael Aug 21 '19 at 19:21
  • No this doesn't update user interface. – Oliver Aug 21 '19 at 20:54

0 Answers0