Why is 'Simulate Background Fetch' leading to crash (libsystem_kernel.dylib`mach_msg_trap) since Xcode 8?

问题

I'm on macOS Sierra, Xcode 8, and get crashes whenever I try to Simulate Background Fetch on an actual iOS 10 device. This does NOT occur when using the simulator. This occurs in all projects, including those freshly created.

    libsystem_kernel.dylib`mach_msg_trap:
    0x18cfec164 <+0>: movn   x16, #0x1e
    0x18cfec168 <+4>: svc    #0x80
->  0x18cfec16c <+8>: ret   (Thread 1: signal SIGSTOP)

I don't have any other iOS devices to test with; is anyone else experiencing this?

回答1:

You aren't alone - I'm encountering this as well. Really annoying. I've just filed a bug.

回答2:

I'm running Xcode 8.1 with a device - it's not crashing but it's hitting a breakpoint that you can't find/edit/remove.

I go to Debug > Continue and it carries on as expected.

回答3:

As pointed out by others. it is not a crash, but an auto breakpoint triggered by system. As explained here by eskimo:

So, why does it stop in mach_msg_trap? The goal is to give you a chance to set a breakpoint in your background fetch handling code, so Xcode forces your app to stop, just like it would if you hit the pause button (Debug > Pause). It stops in mach_msg_trap because that’s where your main thread is sitting when your app is suspended in the background. In short, when you do a Debug > Simulate Background Fetch and stop in mach_msg_trap:

That’s expected behaviour

It’s not a sign of any problem

You can safely continue execution via Debug > Continue

Personally, I see it more like a bug than a feature.

回答4:

It's not crashing, something is throwing a signal to pause execution of the app. Without knowing how the simulated fetch happens I can only guess why - it might be part of the simulation or a side effect of the way the app handles it. Xcode used to support permanently disabling breaks on signals (SIGPIPE was always my bane), but that hasn't worked for several versions now.

回答5:

TARGETS -> Gapabilities -> Background Modes -> ON

and check [Audio, AirPlay, and Picture in Picture]

It worked for me.

回答6:

I just had this issue, it had something to do with pulling data from my backend and a casting type.

If you aren't familiar with firebase just look at the last two lines of this. If you are, here is how I fixed it. My data coming in looked something like this

"Node" : {
      "SubNode" : {
        "-KoB8OMIO0PLiTs8fUkJ" : {
      "ImageName" : "DSC05833-2.jpg",
      "price" : 100,
    },
    "-KoB8Rh9PtSMaMUlaD91" : {
      "ImageName" : "DSC05780-2.jpg",
      "price" : 0,
    },

And my code to pull.

ref.child("Node").child("SubNode").child(uniqueidID).observeSingleEvent(of: DataEventType.value, with: { (snapshot) in
        if snapshot.childrenCount > 0
        {
            let jsonPhoto = snapshot.value as? [String: AnyObject]
            let mageName = jsonPhoto?["ImageName"] as! String            
            photoObj.imagePrice = jsonPhoto?["price"] as! Double //error, Swift didn't catch, just froze my app
        }
})

it worked if value was 100 -> Double, and then for some reason firebase was failing when I casted 0 -> Double

So I fixed how I casted it

I originallyy had this:

photoObj.imagePrice = jsonPhoto?["price"] as! Double // caused error

to..

 photoObj.imagePrice = jsonPhoto?["price"] as? Double ?? 0.00 //fixed error

来源：https://stackoverflow.com/questions/39623664/why-is-simulate-background-fetch-leading-to-crash-libsystem-kernel-dylibmach

标签

ios

xcode8