I created a new swift project, and changed nothing to the project. It is just an empty swift project. If I choose to run on iPhone 6, the springboard will crash. But if I choose others (like iPhone 5s or resizeable iPhone, even iPhone 6 Plus), the empty project works fine.
Does anyone know what's wrong with my xcode? And how should I deal with this problem?
The error message was so long that I cannot attach the whole message here. I'll choose some part that seems important to me.
Process: SpringBoard [1047]
Path: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/System/Library/CoreServices/SpringBoard.app/SpringBoard
Identifier: SpringBoard
Version: 1.0 (50)
Code Type: X86-64 (Native)
Parent Process: launchd_sim [1035]
Responsible: launchd_sim [1035]
User ID: 501
OS Version: Mac OS X 10.10.2 (14C109)
Report Version: 11
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Application Specific Information:
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** setObjectForKey: key cannot be nil'
terminating with uncaught exception of type NSException
abort() called
CoreSimulator 110.4 - Device: iPhone 6 - Runtime: iOS 8.1 (12B411) - DeviceType: iPhone 6
External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 714
thread_create: 0
thread_set_state: 160
VM Region Summary:
ReadOnly portion of Libraries: Total=283.3M resident=110.5M(39%) swapped_out_or_unallocated=172.8M(61%)
Writable regions: Total=176.0M written=49.6M(28%) resident=67.4M(38%) swapped_out=0K(0%) unallocated=108.6M(62%)
REGION TYPE VIRTUAL
=========== =======
CG raster data 2252K
CoreAnimation 324K
CoreData Object IDs 4100K
CoreServices 524K
CoreUI image data 240K
Dispatch continuations 8192K
Foundation 4K
Image IO 12K
Kernel Alloc Once 8K
MALLOC 105.3M
MALLOC (admin) 32K
OpenGL GLSL 128K
SQLite page cache 128K
STACK GUARD 56.1M
Stack 21.8M
VM_ALLOCATE 16.7M
__DATA 35.2M
__GLSLBUILTINS 952K
__LINKEDIT 70.9M
__TEXT 212.5M
__UNICODE 544K
mapped file 89.9M
shared memory 68K
=========== =======
TOTAL 625.5M
Model: MacBookAir6,2, BootROM MBA61.0099.B18, 2 processors, Intel Core i5, 1.3 GHz, 4 GB, SMC 2.13f15
Graphics: Intel HD Graphics 5000, Intel HD Graphics 5000, Built-In
Memory Module: BANK 0/DIMM0, 2 GB, DDR3, 1600 MHz, 0x02FE, 0x45424A3230554638454455302D474E2D4620
Memory Module: BANK 1/DIMM0, 2 GB, DDR3, 1600 MHz, 0x02FE, 0x45424A3230554638454455302D474E2D4620
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x117), Broadcom BCM43xx 1.0 (7.15.159.13.12)
Bluetooth: Version 4.3.2f6 15235, 3 services, 27 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
Network Service: Thunderbolt Bridge, Ethernet, bridge0
Serial ATA Device: APPLE SSD SD0256F, 251 GB
USB Device: Internal Memory Card Reader
USB Device: BRCM20702 Hub
USB Device: Bluetooth USB Host Controller
Thunderbolt Bus: MacBook Air, Apple Inc., 23.6
The problem was solved automatically after I update my Xcode into the latest version.
If you have a possible answer for the question, you are still welcomed to answer the question.
Related
I have a location service based tracking and geofencing app which would run for days and weeks in the background on and iOS 12.2 ff device.
Now with iOS 13.2 the app gets terminated after a variable amount of time, but at least several hours, due to excessive cpu usage:
Date/Time: 2019-11-09 23:25:18 +0200
End time: 2019-11-09 23:26:06 +0200
OS Version: iPhone OS 13.2 (Build 17B84)
Architecture: arm64
Report Version: 29
Incident Identifier: 5B46660C-A347-477F-8AE2-B1401080892B
Data Source: Microstackshots
Shared Cache: 0x44db8000 94FD24C8-F407-3A82-8D27-367F5B6C7BEC
Command: Anchorwatch
Path: /private/var/containers/Bundle/Application/32CD03B2-449C-4E84-8E06-79FA9B50F3A9/Anchorwatch.app/Anchorwatch
Identifier: de.sioned.Anchorwatch
Version: 2.2.1 (14)
Beta Identifier: 68A95EFC-B341-476C-9277-D711242471EC
PID: 57424
Event: cpu usage
Action taken: Process killed
CPU: 48 seconds cpu time over 48 seconds (99% cpu average), exceeding limit of 80% cpu over 60 seconds
CPU limit: 48s
Limit duration: 60s
CPU used: 48s
CPU duration: 48s
Duration: 48.39s
Duration Sampled: 14.08s
Steps: 16
Hardware model: iPad6,12
Active cpus: 2
Heaviest stack for the target process:
16 ??? (libsystem_pthread.dylib + 49032) [0x1c4f64f88]
16 ??? (libdispatch.dylib + 74516) [0x1c4ecb314]
16 ??? (libdispatch.dylib + 36344) [0x1c4ec1df8]
16 ??? (libdispatch.dylib + 33488) [0x1c4ec12d0]
16 ??? (libdispatch.dylib + 104312) [0x1c4ed2778]
16 ??? (libdispatch.dylib + 33948) [0x1c4ec149c]
16 ??? (libdispatch.dylib + 124996) [0x1c4ed7844]
16 ??? (libdispatch.dylib + 125216) [0x1c4ed7920]
16 ??? (libsystem_kernel.dylib + 158196) [0x1c50419f4]
Powerstats for: Anchorwatch [57424]
Bundle ID: de.sioned.Anchorwatch
Adam ID: 0
Is first party: No
App version: 2.2.1
Build version: 14
Is Beta: No
Share with Devs: No
UUID: 1C943425-70F9-3670-98D0-45D3051B4BB7
Path: /private/var/containers/Bundle/Application/32CD03B2-449C-4E84-8E06-79FA9B50F3A9/Anchorwatch.app/Anchorwatch
Architecture: arm64
Footprint: 1046.66 MB
Start time: 2019-11-09 23:25:52 +0200
End time: 2019-11-09 23:26:06 +0200
Num samples: 16 (100%)
CPU Time: 13.971s
Primary state: 15 samples Non-Frontmost App, Non-Suppressed, Kernel mode, Effective Thread QoS Background, Requested Thread QoS Default, Override Thread QoS Unspecified
User Activity: 0 samples Idle, 0 samples Active, 16 samples Unknown
Power Source: 0 samples on Battery, 0 samples on AC, 16 samples Unknown
16 _pthread_wqthread + 275 (libsystem_pthread.dylib + 49032) [0x1c4f64f88]
16 _dispatch_workloop_worker_thread + 587 (libdispatch.dylib + 74516) [0x1c4ecb314]
16 _dispatch_lane_invoke$VARIANT$mp + 419 (libdispatch.dylib + 36344) [0x1c4ec1df8]
16 _dispatch_lane_serial_drain$VARIANT$mp + 299 (libdispatch.dylib + 33488) [0x1c4ec12d0]
16 _dispatch_mach_invoke$VARIANT$mp + 471 (libdispatch.dylib + 104312) [0x1c4ed2778]
16 _dispatch_lane_serial_drain$VARIANT$mp + 759 (libdispatch.dylib + 33948) [0x1c4ec149c]
16 _dispatch_event_loop_drain$VARIANT$mp + 315 (libdispatch.dylib + 124996) [0x1c4ed7844]
16 _dispatch_kq_drain + 123 (libdispatch.dylib + 125216) [0x1c4ed7920]
16 kevent_id + 8 (libsystem_kernel.dylib + 158196) [0x1c50419f4]
1 <User mode>
Binary Images:
0x102d80000 - ??? Anchorwatch <1C943425-70F9-3670-98D0-45D3051B4BB7> /private/var/containers/Bundle/Application/32CD03B2-449C-4E84-8E06-79FA9B50F3A9/Anchorwatch.app/Anchorwatch
0x1c4eb9000 - 0x1c4f2dfff libdispatch.dylib <B7EED4C7-560D-3DA6-9B50-ED52A150AAC6> /usr/lib/system/libdispatch.dylib
0x1c4f59000 - 0x1c4f69fff libsystem_pthread.dylib <F8B082D8-24D9-3B1E-B80B-645FC8A88E14> /usr/lib/system/libsystem_pthread.dylib
0x1c501b000 - 0x1c5048fff libsystem_kernel.dylib <AE4C3D7A-7D08-33E7-BCC6-11AC821B4E48> /usr/lib/system/libsystem_kernel.dylib
While in background the app does nothing more than to write each location update to a sqlite database and checking the current location against a safety perimeter.
There is no reason to assume that the app suddenly after several hours would require such a high cpu usage.
I have not the slightest idea how to approach the problem and I am not even sure if I can do anything about it or if it is a bug in 13.2 and I have to wait for a fix.
My first assumption was, that the old iOS 12.0 bug which terminated background apps without reason and which was fixed in 12.2 was back. But that here seems to be something new. I was able to run the test app iOS 12 terminates apps in the background for no reason for several days.
Any hint how to interprete the log and take action ?
Edit:
It seems, that this is related to iOS 13.2 message: nehelper sent invalid result code [1] for Wi-Fi information request
Location service queries the WiFi interface in second intervals. Instrument shows that these query calls have a memory leak.
Turning off WiFi on the device seems to solve the problem, though that is no true solution. Now waiting for iOS 13.3 to leave beta.
It turned out, that a third party framework that I am using launches calls to CNCopyNetworkInfo in second intervals. These calls could not fullfilled as my App had no WiFi capabilities enabled and thus the calls to CNCopyNetworkInfo caused small memory leaks that added up over time.
After enabling WiFi access capabilities the memory leaks vanished.
I've seen a fair bit of noise about "false positives," and have even encountered them, myself.
However, this takes the cake.
Easy to reproduce, using Swift 5/Xcode 10.2, create a new single-view iOS app.
Run Leaks.
You get these critters:
Malloc 64 Bytes 1 0x600001d084c0 64 Bytes Foundation +[NSString stringWithUTF8String:]
Malloc 16 Bytes 3 < multiple > 48 Bytes
Malloc 1.50 KiB 3 < multiple > 4.50 KiB
Malloc 32 Bytes 3 < multiple > 96 Bytes
Malloc 8.00 KiB 1 0x7fc56f000c00 8.00 KiB
Malloc 64 Bytes 10 < multiple > 640 Bytes
Malloc 80 Bytes 3 < multiple > 240 Bytes
Malloc 4.00 KiB 3 < multiple > 12.00 KiB
Using the simulator (XR, iOS 12.2).
That first one has a stack trace, but it's worthless.
Is there some way that I can correct for this noise? I'm writing an infrastructure component, and I need to:
A) Make damn sure it doesn't leak, and
B) Not have every Cocoapod jockey on Earth emailing me, and telling me that my component leaks.
If using a iOS 12.1 simulator , the leak instrument still can work (Swift 5/Xcode 10.2). Currently we are hoping it will be fixed in future versions.
I want to dump the memory pages of a process once it finishes execution. I'm trying to use gdb for that, First I set break points at exit and _exit then I run the process inside gdb, once the process breaks I use info proc mappings to get the memory map of the process. it looks like the following:
Mapped address spaces:
Start Addr End Addr Size Offset objfile
0x400000 0x415000 0x15000 0x0 /path/workspace/freqmine
0x614000 0x615000 0x1000 0x14000 /path/workspace/freqmine
0x615000 0x616000 0x1000 0x15000 /path/workspace/freqmine
0x616000 0x129b000 0xc85000 0x0 [heap]
0x7ffff71f4000 0x7ffff720a000 0x16000 0x0 /lib/x86_64-linux-gnu/libgcc_s.so.1
0x7ffff720a000 0x7ffff7409000 0x1ff000 0x16000 /lib/x86_64-linux-gnu/libgcc_s.so.1
0x7ffff7409000 0x7ffff740a000 0x1000 0x15000 /lib/x86_64-linux-gnu/libgcc_s.so.1
0x7ffff740a000 0x7ffff750f000 0x105000 0x0 /lib/x86_64-linux-gnu/libm-2.19.so
0x7ffff750f000 0x7ffff770e000 0x1ff000 0x105000 /lib/x86_64-linux-gnu/libm-2.19.so
0x7ffff770e000 0x7ffff770f000 0x1000 0x104000 /lib/x86_64-linux-gnu/libm-2.19.so
0x7ffff770f000 0x7ffff7710000 0x1000 0x105000 /lib/x86_64-linux-gnu/libm-2.19.so
0x7ffff7710000 0x7ffff78cb000 0x1bb000 0x0 /lib/x86_64-linux-gnu/libc-2.19.so
0x7ffff78cb000 0x7ffff7acb000 0x200000 0x1bb000 /lib/x86_64-linux-gnu/libc-2.19.so
0x7ffff7acb000 0x7ffff7acf000 0x4000 0x1bb000 /lib/x86_64-linux-gnu/libc-2.19.so
0x7ffff7acf000 0x7ffff7ad1000 0x2000 0x1bf000 /lib/x86_64-linux-gnu/libc-2.19.so
0x7ffff7ad1000 0x7ffff7ad6000 0x5000 0x0
0x7ffff7ad6000 0x7ffff7bbc000 0xe6000 0x0 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19
0x7ffff7bbc000 0x7ffff7dbb000 0x1ff000 0xe6000 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19
0x7ffff7dbb000 0x7ffff7dc3000 0x8000 0xe5000 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19
0x7ffff7dc3000 0x7ffff7dc5000 0x2000 0xed000 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19
0x7ffff7dc5000 0x7ffff7dda000 0x15000 0x0
0x7ffff7dda000 0x7ffff7dfd000 0x23000 0x0 /lib/x86_64-linux-gnu/ld-2.19.so
0x7ffff7fce000 0x7ffff7fd3000 0x5000 0x0
0x7ffff7ff7000 0x7ffff7ffa000 0x3000 0x0
0x7ffff7ffa000 0x7ffff7ffc000 0x2000 0x0 [vdso]
0x7ffff7ffc000 0x7ffff7ffd000 0x1000 0x22000 /lib/x86_64-linux-gnu/ld-2.19.so
0x7ffff7ffd000 0x7ffff7ffe000 0x1000 0x23000 /lib/x86_64-linux-gnu/ld-2.19.so
0x7ffff7ffe000 0x7ffff7fff000 0x1000 0x0
0x7ffffffdd000 0x7ffffffff000 0x22000 0x0 [stack]
0xffffffffff600000 0xffffffffff601000 0x1000 0x0 [vsyscall]
Now I have two questions, first: getconf PAGESIZE on my machine returns 4096 which is equal to 0x1000, some of these memory spaces have different sizes though. how is that possible? are these spaces memory pages or just logical spaces? if these are not memory pages, how can I view the addresses of memory pages, or even directly dump memory pages to files?
my second question is the following: these addresses are supposed to be virtual addresses viewed by the program (not physical addresses), so why doesn't the program space start at 0? if I try to dump the memory starting from address 0 I get the following error: Cannot access memory at address 0x0. also why are there some regions in between these memory spaces that cannot be accessed (the region after the heap for example)? shouldn't the virtual space of a process be contiguous?
some of these memory spaces have different sizes though. how is that possible?
Easy: they span multiple pages (note that all of their sizes are multiples of 0x1000).
are these spaces memory pages or just logical spaces?
They are spans of one or more pages that have the same underlying mapping (the same file) and the same protections. I am not sure what exactly you call "logical spaces", but chances are you can call them that.
these addresses are supposed to be virtual addresses viewed by the program (not physical addresses),
Correct.
so why doesn't the program space start at 0?
Because long time ago VAX machines used to map something at address 0, and that made finding NULL pointer dereferences hard (they didn't crash). This was decided to be a bad idea, so later UNIX variants do not map zero page, and any attempt to dereference a NULL pointer causes SIGSEGV, helping you to debug your programs.
I am currently using Xcode 5 on my Macbook Pro which is running OSX Yosemite. I am trying to create an outlet from a UIWebview to a header file. When I let go of my mouse to create the connection, Xcode freezes and crashes. This is repeatedly happening no matter what I have done. I have tried restarting Xcode and my Macbook. Does anyone else have this problem or know how to fix it? Thanks!
I have added the logs from the crash(I couldn't include the backtrace because it exceeded the maximum characters in the body)
Process: Xcode [1631]
Path: /Applications/Xcode.app/Contents/MacOS/Xcode
Identifier: com.apple.dt.Xcode
Version: 5.1.1 (5085)
Build Info: IDEFrameworks-5085000000000000~10
App Item ID: 497799835
App External ID: 520942841
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: Xcode [1631]
User ID: 502
Date/Time: 2014-06-26 21:50:34.616 -0400
OS Version: Mac OS X 10.10 (14A238x)
Report Version: 11
Anonymous UUID: 6D3E70F1-91EB-79A5-FAB6-2929D7E8A66F
Sleep/Wake UUID: C86C5452-A655-43AA-9D11-92BE0F080F3E
Time Awake Since Boot: 11000 seconds
Time Since Wake: 510 seconds
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Application Specific Information:
ProductBuildVersion: 5B1008
ASSERTION FAILURE in /SourceCache/DVTFrameworks/DVTFrameworks-5074/DVTKit/ViewControllers/DVTControllerContentView.m:280
Details: <DVTControllerContentView: 0x7fe687d170a0> can only have one subview, its contentView
Object: <DVTControllerContentView: 0x7fe687d170a0>
Method: -addSubview:
Thread: <NSThread: 0x7fe682d086a0>{number = 1, name = main}
Hints: None
External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 1
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 4286
thread_create: 0
thread_set_state: 0
VM Region Summary:
ReadOnly portion of Libraries: Total=404.2M resident=289.4M(72%) swapped_out_or_unallocated=114.9M(28%)
Writable regions: Total=1.2G written=71.9M(6%) resident=141.4M(11%) swapped_out=0K(0%) unallocated=1.1G(89%)
REGION TYPE VIRTUAL
=========== =======
Activity Tracing 2048K
CG backing stores 4084K
CG image 19.3M
CG raster data 92K
CG shared images 1324K
CoreAnimation 880K
CoreAnimation (reserved) 12K reserved VM address space (unallocated)
CoreData Object IDs 4100K
CoreImage 264K
CoreUI image data 180K
Dispatch continuations 4096K
Foundation 16K
IOKit 13.8M
IOKit (reserved) 4K reserved VM address space (unallocated)
Image IO 700K
JS JIT generated code 8K
JS JIT generated code (reserved) 1.0G reserved VM address space (unallocated)
Kernel Alloc Once 8K
MALLOC 114.7M
MALLOC (admin) 32K
Memory Tag 242 12K
Memory Tag 249 156K
Memory Tag 251 80K
OpenCL 16K
OpenGL GLSL 256K
SQLite page cache 4352K
STACK GUARD 56.1M
Stack 15.7M
VM_ALLOCATE 16.9M
WebKit Malloc 464K
__DATA 60.1M
__GLSLBUILTINS 2588K
__IMAGE 528K
__LINKEDIT 100.5M
__TEXT 304.0M
__UNICODE 544K
mapped file 152.6M
shared memory 68K
=========== =======
TOTAL 1.9G
TOTAL, minus reserved VM space 879.9M
Model: MacBookPro7,1, BootROM MBP71.0039.B0E, 2 processors, Intel Core 2 Duo, 2.4 GHz, 8 GB, SMC 1.62f7
Graphics: NVIDIA GeForce 320M, NVIDIA GeForce 320M, PCI, 256 MB
Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1067 MHz, 0x859B, 0x435435313236344243313036372E4D313646
Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1067 MHz, 0x859B, 0x435435313236344243313036372E4D313646
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x8D), Broadcom BCM43xx 1.0 (5.106.98.100.24)
Bluetooth: Version 4.3.0d49 14130, 3 services, 16 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en1
Serial ATA Device: Hitachi HTS545032B9SA02, 320.07 GB
Serial ATA Device: HL-DT-ST DVDRW GS23N
USB Device: Built-in iSight
USB Device: Internal Memory Card Reader
USB Device: BRCM2046 Hub
USB Device: Bluetooth USB Host Controller
USB Device: IR Receiver
USB Device: Apple Internal Keyboard / Trackpad
Thunderbolt Bus:
I think you should declare a IBOutlet in your header file. And then in Storyboard you try to connect the header file.
Have you ever tried to clean your product(Product->Clean)?
Then, open the xib file as source code and delete your IBOutlet info. Maybe XCode get confused about your IBOutlet.
can anyone help me out in interpreting this panic crash log?
this happens during rotation with many images ... it involves javascript if that is of any help.
Incident Identifier: AD3EB83A-2379-4876-BCB3-6C9A4B5DC862
CrashReporter Key: e580be25a4b36b96f0d033b88c3cfebf6232e309
Hardware Model: iPad2,1
Date/Time: 2012-06-27 14:26:41.182 +0200
OS Version: iPhone OS 5.1.1 (9B206)
panic(cpu 1 caller 0x801c6fdb): mbuf_watchdog: 4 waiters stuck for 12 secs
13872/13872 mbufs in use:
13868 mbufs allocated to data
4 mbufs allocated to packet headers
13748/13748 mbuf 2KB clusters in use
0/122 mbuf 4KB clusters in use
31452 KB allocated to network (approx. 98% in use)
mbuf leak detection table:
total captured: 31701 (one per 500)
total allocs outstanding: 42
new hash recorded: 27032 allocs, 26944 traces
hash collisions: 18 allocs, 4669 traces
overwrites: 26449 allocs, 0 traces
lock conflicts: 0
top 5 outstanding traces:
[1] 29 outstanding alloc(s), 30 hit(s), 1 collision(s)
[2] 5 outstanding alloc(s), 26 hit(s), 0 collision(s)
[3] 3 outstanding alloc(s), 2546 hit(s), 0 collision(s)
[4] 3 outstanding alloc(s), 1844 hit(s), 0 collision(s)
[5] 1 outstanding alloc(s), 4662 hit(s), 4661 collision(s)
trace [1] trace [2] trace [3] trace [4] trace [5]
---------- ---------- ---------- ---------- ----------
1: 0x801bff71 0x801bff71 0x801bff71 0x801bff71 0x801bff71
2: 0x801b0df3 0x801b0df3 0x801b0e2b 0x801b0df3 0x801b0df3
3: 0x801bf8b5 0x801c12db 0x801c12db 0x801bf871 0x801b0f39
4: 0x801b0c67 0x801c9517 0x801c9517 0x801b0c67 0x801c08bb
5: 0x801c12db 0x801cece3 0x801cece3 0x801c12db 0x802b7855
6: 0x801c9517 0x801ceb05 0x801ceb05 0x801c9517 0x801be739
7: 0x801cece3 0x801e1bd8 0x801e1bd8 0x801cece3 0x8010e8d5
8: 0x801ceb05 0x801ceb05 0x802b91f5
9: 0x801e1bd8 0x801e1bd8 0x802b937f
10: 0x802b8591
11: 0x8002425b
12:
13:
14:
15:
16:
Debugger message: panic
OS version: 9B206
Kernel version: Darwin Kernel Version 11.0.0: S
Thanks for any insight.
You should use instruments to check memory allocations and memory leaks. It could also be that the app was too long unresponsive and was killed, the text 4 waiters stuck for 12 secs could indicate that. The crash report content and format is pretty unique, haven't seen that one yet. So these are just guesses.