Network Extension VPN provider killed due to EXC_RESOURCE

First of all, you realise this isn’t actually a crash right? Hence the NON-FATAL CONDITION (this is NOT a crash) text in the log.

150/sec seems really low for such network provider which potentially need to handle all traffic in the IOS device.

Indeed. However, I doubt this report is caused by network traffic because you really should only be waking up once per packet and 41438 packet a second for 300 seconds is a lot of networking for iOS. Was your provider really handling that much traffic?

In my experience

EXC_RESOURCE

EXC_RESOURCE

Share and Enjoy
—
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I agree that 41438 wakes is too high. There must be issue somewhere in my VPN provider. But I stil think 150 wakes/sec limit is too low for the provider. It is possible that the number of wakeups is in the range of thousand. Currently the throughput in wireless device can easily reach 10Mbits/s. If the length of packet is about 1500 bytes, then the number of the packets per second would be 873.

Currently the throughput in wireless device can easily reach 10Mbits/s. If the length of packet is about 1500 bytes, then the number of the packets per second would be 873.

Your logic assumes that:

• the network will be running at full speed for all of the 300 seconds

• the device is fast enough that your process has the chance to sleep that many times per second

I’m not sure that this will happen in the real world. So, my advice is that you focus on the cause of the immediate problem (the crazy high number of wakes) and then, once that’s sorted out, test your provider to see if this actually happens in realistic scenarios.

Share and Enjoy
—
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks for the advice. I will reduce the wakeups in my network provider, then try to explore some real world scenarios (e.g. video streaming) that would require over 150 wakeups/sec.

We have this problem in our app as well. Once in a while it saves a log file to the device that shows excessive wakeups but different threads getting excessive wakeup at different app kill times. We tried disabling a websocket library (https://github.com/socketio/socket.io-client-swift) that showed up in a bare majority of the crashes but it happens in other threads now. It kills Instruments tool as well when we tried to narrow it down. Have some crash logs file with "this is NOT a crash" for the Apple Instruments app com.apple.dt.instruments.DVTInstrumentsFoundation.

But most of the times no log file gets saved. And it does not happen on the simulator. A tricky one to debug. Would be good if atleast a log file is consistently saved to the device. The message that "this is NOT a crash" is kind of strange because for all practical purposes the app did crash and device log type column shows "Crash". So either fix the log type column or the message should be fixed and the log file should be created more reliably. If it is really not a crash I assume there is sufficient time to write the device log each time before killing it. This is with a Swift 2.0 app on iOS 9.3.3 and iPhone 6 plus.

hello xuzhuang,

I met the same probelm, did you fix it?