Using appmanifest, generated with manifestation tool that excludes physics engines results in a crash when an app is suspended on iOS.
Test project.
PhysicsNullCrash.zip (3.3 KB)
Crash report.
PhysicsNullCrash-2019-11-11-135704.txt (63.3 KB)
2 Likes
Thanks. We’ll look into this during the week.
1 Like
Will the fix be available in 1.2.164?
I tested the sample app you sent me on two different iOS devices (iOS 9 and 13) and wasn’t able to get it to crash in 1.2.163. When you say “when an app is suspended on iOS” what do you mean specifically?
I mean run the app, press the home button to go to the main screen of your device, wait a few seconds. You will see a crash report in the log of the Console on your device and you can go to Settings->Privacy->Analytics->Analytics Data and see PhysicsNullCrash-*.ips
No crash for me. Nothing in the device console, or device logs in XCode and nothing in the log on the device. And the app is still visible in the list of active apps on the device.
Bundling with 1.2.163:
Here is a recording of the whole process with my iPhone 8.
And it’s not only me, I get reports of the crash from our testers too, using various devices.
Please tell me If you need any other information about the crash. We want to cooperate to fix it sooner than later.
Oh, so it’s on the iOS simulator and not on an actual device? I’ve tested on two physical devices without any crashes. But you write:
Which indicates that it crashes on actual hardware as well.
Which iOS version? Does it matter?
I didn’t try running on iOS Simulator, I don’t think it’s important.
I am testing on real iPhone 8, real iPad Pro 12.9 1st gen with latest iOS.
Doesn’t seem to crash on iPad 2 with iOS 9.3.5, that is 32 bit device.
On the video I am using QuickTime Player to show the screen of my real device for the recording and you can see ARM-64 in the crash report.
Ah, I see! Sorry about that. The problem still remains though, it does not crash when I try.
Could you please bundle and share the ipa and the dsym folder (check the Generate Debug Symbols checkbox in the bundle dialog)?
1 Like
Here is the ipa file built with generate debug symbols checked. But I don’t see a dsym folder, where do I find it?
Physics Null Crash.ipa.zip (3.1 MB)
You should be able to find the .dSYM folder under the build folder.
(In the next release it will be bundled properly next to your .app bundle)
1 Like
Still don’t see it, anything wrong with my machine?
Hmm, then I must be mistaken (and confused).
Could you chek inside the build.zip?
So the problem is that the app is killed by a watch dog on iOS that prevents apps from running too long in background.
When debugging a process with Xcode or ios-deploy -d the watch dog is disabled, however lldb allowed me to see a clue of where is the problem.
Here is the output for an app with included physics engine (it doesn’t crash). I suspend it and after about 5 seconds I execute thread 1 backtrace.
(lldb) process interrupt
Process 4676 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
frame #0: 0x000000019d4dd238 libsystem_kernel.dylib`__semwait_signal + 8
libsystem_kernel.dylib`__semwait_signal:
-> 0x19d4dd238 <+8>: b.lo 0x19d4dd254 ; <+36>
0x19d4dd23c <+12>: stp x29, x30, [sp, #-0x10]!
0x19d4dd240 <+16>: mov x29, sp
0x19d4dd244 <+20>: bl 0x19d4bbf4c ; cerror
Target 0: (PhysicsNullCrash) stopped.
(lldb) thread backtrace 1
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
* frame #0: 0x000000019d4dd238 libsystem_kernel.dylib`__semwait_signal + 8
frame #1: 0x000000019d349644 libsystem_c.dylib`nanosleep + 212
frame #2: 0x000000019d34951c libsystem_c.dylib`usleep + 64
frame #3: 0x0000000104212854 PhysicsNullCrash`___lldb_unnamed_symbol10$$PhysicsNullCrash + 196
frame #4: 0x0000000104275f68 PhysicsNullCrash`___lldb_unnamed_symbol1191$$PhysicsNullCrash + 40
frame #5: 0x000000010421379c PhysicsNullCrash`___lldb_unnamed_symbol14$$PhysicsNullCrash + 192
frame #6: 0x0000000104213628 PhysicsNullCrash`___lldb_unnamed_symbol13$$PhysicsNullCrash + 120
frame #7: 0x0000000104213874 PhysicsNullCrash`___lldb_unnamed_symbol17$$PhysicsNullCrash + 124
frame #8: 0x000000019d4e7460 libdyld.dylib`start + 4
As you can see nothing much is happening, the app is waiting to be resumed.
But here is the output for an app with excluded physics engine. Same pause after about 5 seconds of suspension.
(lldb) process interrupt
Process 4668 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
frame #0: 0x000000019d4dd238 libsystem_kernel.dylib`__semwait_signal + 8
libsystem_kernel.dylib`__semwait_signal:
-> 0x19d4dd238 <+8>: b.lo 0x19d4dd254 ; <+36>
0x19d4dd23c <+12>: stp x29, x30, [sp, #-0x10]!
0x19d4dd240 <+16>: mov x29, sp
0x19d4dd244 <+20>: bl 0x19d4bbf4c ; cerror
Target 0: (PhysicsNullCrash) stopped.
(lldb) thread backtrace 1
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
* frame #0: 0x000000019d4dd238 libsystem_kernel.dylib`__semwait_signal + 8
frame #1: 0x000000019d349644 libsystem_c.dylib`nanosleep + 212
frame #2: 0x000000019d34951c libsystem_c.dylib`usleep + 64
frame #3: 0x00000001044a1860 PhysicsNullCrash`dmEngine::Step(dmEngine::Engine*) + 196
frame #4: 0x00000001045286ac PhysicsNullCrash`dmGraphics::RunApplicationLoop(void*, void (*)(void*), int (*)(void*)) + 40
frame #5: 0x00000001044a27a8 PhysicsNullCrash`dmEngine::InitRun(dmEngineService::EngineService*, int, char**, void (*)(dmEngine::Engine*, void*), void (*)(dmEngine::Engine*, void*), void*) + 192
frame #6: 0x00000001044a2634 PhysicsNullCrash`dmEngine::Launch(int, char**, void (*)(dmEngine::Engine*, void*), void (*)(dmEngine::Engine*, void*), void*) + 120
frame #7: 0x00000001044a2880 PhysicsNullCrash`engine_main(int, char**) + 124
frame #8: 0x000000019d4e7460 libdyld.dylib`start + 4
It’s running inside the dmEngine::Step() function. So the watch dog kills the app.
What could it be inside that function?
1 Like
Nice find!
Well, the Step() function is the main loop function of the engine.
I really cannot think of why its behavior would be different from having physics included vs excluded 
2 Likes
Any progress? I can run a custom engine with some debug output for you.
No progress, full effort was put into releasing.
We’ll continue investigating this week
I do think i could reproduce it though, even though it just meant the screen flickered when the app restarted.
1 Like
Just tested with Defold 164, looks like the crash is now gone! So somehow it was related to the iOS bootstrapping…
Still strange, I’ll keep an eye on that.
2 Likes