iOS iPad panic crash log interpret - ios

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.

Related

Ceph cluster down, Reason OSD Full - not starting up

Cephadm Pacific v16.2.7
Our Ceph cluster is stuck pgs degraded and osd are down
Reason:- OSD's got filled up
Things we tried
Changed vale to to maximum possible combination (not sure if done right ?)
backfillfull < nearfull, nearfull < full, and full < failsafe_full
ceph-objectstore-tool - tried to delte some pgs to recover space
tried to mount osd and delete pg's to recover some space, but not sure how to do it in bluestore .
Global Recovery Event - stuck for ever
ceph -s
cluster:
id: a089a4b8-2691-11ec-849f-07cde9cd0b53
health: HEALTH_WARN
6 failed cephadm daemon(s)
1 hosts fail cephadm check
Reduced data availability: 362 pgs inactive, 6 pgs down, 287 pgs peering, 48 pgs stale
Degraded data redundancy: 5756984/22174447 objects degraded (25.962%), 91 pgs degraded, 84 pgs undersized
13 daemons have recently crashed
3 slow ops, oldest one blocked for 31 sec, daemons [mon.raspi4-8g-18,mon.raspi4-8g-20] have slow ops.
services:
mon: 5 daemons, quorum raspi4-8g-20,raspi4-8g-25,raspi4-8g-18,raspi4-8g-10,raspi4-4g-23 (age 2s)
mgr: raspi4-8g-18.slyftn(active, since 3h), standbys: raspi4-8g-12.xuuxmp, raspi4-8g-10.udbcyy
osd: 19 osds: 15 up (since 2h), 15 in (since 2h); 6 remapped pgs
data:
pools: 40 pools, 636 pgs
objects: 4.28M objects, 4.9 TiB
usage: 6.1 TiB used, 45 TiB / 51 TiB avail
pgs: 56.918% pgs not active
5756984/22174447 objects degraded (25.962%)
2914/22174447 objects misplaced (0.013%)
253 peering
218 active+clean
57 undersized+degraded+peered
25 stale+peering
20 stale+active+clean
19 active+recovery_wait+undersized+degraded+remapped
10 active+recovery_wait+degraded
7 remapped+peering
7 activating
6 down
2 active+undersized+remapped
2 stale+remapped+peering
2 undersized+remapped+peered
2 activating+degraded
1 active+remapped+backfill_wait
1 active+recovering+undersized+degraded+remapped
1 undersized+peered
1 active+clean+scrubbing+deep
1 active+undersized+degraded+remapped+backfill_wait
1 stale+active+recovery_wait+undersized+degraded+remapped
progress:
Global Recovery Event (2h)
[==========..................] (remaining: 4h)
'''
Some versions of BlueStore were susceptible to BlueFS log growing extremely large - beyond the point of making booting OSD impossible. This state is indicated by booting that takes very long and fails in _replay function.
This can be fixed by::
ceph-bluestore-tool fsck –path osd path –bluefs_replay_recovery=true
It is advised to first check if rescue process would be successful::
ceph-bluestore-tool fsck –path osd path –bluefs_replay_recovery=true –bluefs_replay_recovery_disable_compact=true
If above fsck is successful fix procedure can be applied
Special Thank you to, this has been solved with the help of a dewDrive Cloud backup faculty Member

App terminated due to cpu use in iOS 13.2

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.

"no next heap size found: 18446744071789822643, offset 0"

I've written a simulator, which is distributed over two hosts. When I launch a few thousand processes, after about 10 minutes and half a million events written, my main Erlang (OTP v22) virtual machine crashes with this message:
no next heap size found: 18446744071789822643, offset 0.
It's always that same number - 18446744071789822643.
Because my server is very capable, the crash dump is also huge and I can't view it on my headless server (no WX installed).
Are there any tips on what I can look at?
What would be the first things I can try out to debug this issue?
First, see what memory() says:
> memory().
[{total,18480016},
{processes,4615512},
{processes_used,4614480},
{system,13864504},
{atom,331273},
{atom_used,306525},
{binary,47632},
{code,5625561},
{ets,438056}]
Check which one is growing - processes, binary, ets?
If it's processes, try typing i(). in the Erlang shell while the processes are running. You'll see something like:
Pid Initial Call Heap Reds Msgs
Registered Current Function Stack
<0.0.0> otp_ring0:start/2 233 1263 0
init init:loop/1 2
<0.1.0> erts_code_purger:start/0 233 44 0
erts_code_purger erts_code_purger:wait_for_request 0
<0.2.0> erts_literal_area_collector:start 233 9 0
erts_literal_area_collector:msg_l 5
<0.3.0> erts_dirty_process_signal_handler 233 128 0
erts_dirty_process_signal_handler 2
<0.4.0> erts_dirty_process_signal_handler 233 9 0
erts_dirty_process_signal_handler 2
<0.5.0> erts_dirty_process_signal_handler 233 9 0
erts_dirty_process_signal_handler 2
<0.8.0> erlang:apply/2 6772 238183 0
erl_prim_loader erl_prim_loader:loop/3 5
Look for a process with a very big heap, and that's where you'd start looking for a memory leak.
(If you weren't running headless, I'd suggest starting Observer with observer:start(), and look at what's happening in the Erlang node.)

Springboard Quit Unexpectedly for Empty Swift Project

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.

Xcode crashes when I try to create a outlet from a UIWebview to Header file

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.

Resources