Kernel deadlock in mach exception handling
Originator: | landon.j.fuller | ||
Number: | rdar://14700448 | Date Originated: | 09-Aug-2013 02:14 PM |
Status: | Open | Resolved: | |
Product: | OS X | Product Version: | 12E55 |
Classification: | Crash/Hang/Data Loss | Reproducible: | Always |
09-Aug-2013 02:14 PM Landon Fuller: Summary: When running the attached project under a debugger, the kernel will deadlock around proclist-related locks. This looks to be related to exit() being called while a Mach message response has not yet been dispatched. Steps to Reproduce: Run the attached project under a debugger. Expected Results: It doesn't do anything useful, but it also doesn't deadlock your machine. Actual Results: The process itself will deadlock in the kernel. Any other code that acquires related locks will lock up, too. Rebooting will lock up, for the same reason. Notes: Stack traces from a machine exhibiting this behavior: task vm_map ipc_space #acts pid process io_policy wq_state command 0xffffff802dc883a8 0xffffff802f5af220 0xffffff802c5c2ae0 3 280 0xffffff802f92a000 1 0 0 otest thread thread_id processor pri io_policy state wait_queue wait_event 0xffffff802fb2c7e8 0x668 0xffffff80270bfc28 31 W 0xffffff80301c6400 0x0 kernel_stack=0xffffff8074ad8000 stacktop=0xffffff8074adb4e0 0xffffff8074adb4e0 0xffffff8026a2e8c1 <thread_invoke+1281> 0xffffff8074adb560 0xffffff8026a2db8c <thread_block_reason+300> 0xffffff8074adb5a0 0xffffff8026a13112 <get_active_thread> // actually ipc_mqueue_receive() 0xffffff8074adb5c0 0xffffff8026a20f96 <mach_msg_rpc_from_kernel_body+278> 0xffffff8074adb620 0xffffff8026a4da52 <mach_exception_raise+178> 0xffffff8074adb6c0 0xffffff8026a1e43b <exception_deliver+523> 0xffffff8074adbe70 0xffffff8026a1e6cd <bsd_exception+61> 0xffffff8074adbe80 0xffffff8026d680b1 <issignal_locked+977> 0xffffff8074adbf10 0xffffff8026d68d9f <bsd_ast+847> 0xffffff8074adbf50 0xffffff8026a1b6e1 <ast_taken+209> 0xffffff8074adbf90 0xffffff8026ab8c63 <i386_astintr+35> 0xffffff8074adbfb0 0xffffff8026ace14c <return_from_trap+156> stackbottom=0xffffff8074adbfb0 thread thread_id processor pri io_policy state wait_queue wait_event 0xffffff802d16c270[WQ] 0x673 0xffffff80270bfc28 31 W 0xffffff802d790bc0 0x0 continuation=0xffffff8026d4f9c0 <kqueue_scan_continue> thread thread_id processor pri io_policy state wait_queue wait_event 0xffffff802e6fdb58 0x68b 0xffffff80270bfc28 31 W 0xffffff80605f4c00 0xffffff802f92a208 "unknown" kernel_stack=0xffffff8074a38000 stacktop=0xffffff8074a3bce0 0xffffff8074a3bce0 0xffffff8026a2e8c1 <thread_invoke+1281> 0xffffff8074a3bd60 0xffffff8026a2db8c <thread_block_reason+300> 0xffffff8074a3bda0 0xffffff8026a2664e <lck_mtx_sleep+78> 0xffffff8074a3bdd0 0xffffff8026d69dd6 <_sleep+246> 0xffffff8074a3be50 0xffffff8026d6a1c4 <msleep+116> 0xffffff8074a3be90 0xffffff8026d6840d <sig_try_locked+93> 0xffffff8074a3bed0 0xffffff8026d565d6 <exit1_internal+310> 0xffffff8074a3bf40 0xffffff8026d56479 <exit+25> 0xffffff8074a3bf50 0xffffff8026de16aa <unix_syscall64+522> 0xffffff8074a3bfb0 0xffffff8026ace9c3 <hndl_unix_scall64+19> stackbottom=0xffffff8074a3bfb0 task vm_map ipc_space #acts pid process io_policy wq_state command 0xffffff802e4a0af8 0xffffff802e44b570 0xffffff802c5c23f0 5 136 0xffffff802e4b9020 1 0 0 Terminal thread thread_id processor pri io_policy state wait_queue wait_event 0xffffff802f4b5d98 0x32e 0xffffff80270bfc28 47 UW 0xffffff80605f4340 0xffffff802f92a15c "proc_signstart" kernel_stack=0xffffff8074a98000 stacktop=0xffffff8074a9b5e0 0xffffff8074a9b5e0 0xffffff8026a2e8c1 <thread_invoke+1281> 0xffffff8074a9b660 0xffffff8026a2db8c <thread_block_reason+300> 0xffffff8074a9b6a0 0xffffff8026a2664e <lck_mtx_sleep+78> 0xffffff8074a9b6d0 0xffffff8026d69dd6 <_sleep+246> 0xffffff8074a9b750 0xffffff8026d6a1c4 <msleep+116> 0xffffff8074a9b790 0xffffff8026d606cc <proc_transwait+92> 0xffffff8074a9b7d0 0xffffff8026d605d5 <proc_iterate+597> 0xffffff8074a9b840 0xffffff8026d6bb62 <sysctl_prochandle+418> 0xffffff8074a9bd50 0xffffff8026d6e38f <sysctl_root+543> 0xffffff8074a9bdb0 0xffffff8026d6e58b <userland_sysctl+187> 0xffffff8074a9be90 0xffffff8026d6a800 <__sysctl+688> 0xffffff8074a9bf50 0xffffff8026de16aa <unix_syscall64+522> 0xffffff8074a9bfb0 0xffffff8026ace9c3 <hndl_unix_scall64+19> stackbottom=0xffffff8074a9bfb0 thread thread_id processor pri io_policy state wait_queue wait_event 0xffffff802f4ad4e0[WQ] 0x372 0xffffff80270bfc28 49 W 0xffffff802e7348c0 0x0 continuation=0xffffff8026d4f9c0 <kqueue_scan_continue> thread thread_id processor pri io_policy state wait_queue wait_event 0xffffff802f4a6780 0x38a 0xffffff80270bfc28 47 W 0xffffff802e734840 0x0 Thread Name: com.apple.terminal.low-disk-space-handler continuation=0xffffff8026d4f9c0 <kqueue_scan_continue> thread thread_id processor pri io_policy state wait_queue wait_event 0xffffff802e3bc4e0 0x3c6 0xffffff80270bfc28 47 W 0xffffff80605f4f20 0xffffff802de6dec0 "piperd" Thread Name: com.apple.terminal.sigchld-handler kernel_stack=0xffffff8074ab0000 stacktop=0xffffff8074ab3c50 0xffffff8074ab3c50 0xffffff8026a2e8c1 <thread_invoke+1281> 0xffffff8074ab3cd0 0xffffff8026a2db8c <thread_block_reason+300> 0xffffff8074ab3d10 0xffffff8026a2664e <lck_mtx_sleep+78> 0xffffff8074ab3d40 0xffffff8026d69dd6 <_sleep+246> 0xffffff8074ab3dc0 0xffffff8026d6a1c4 <msleep+116> 0xffffff8074ab3e00 0xffffff8026d7a296 <pipe_read+214> 0xffffff8074ab3e50 0xffffff8026d7693e <dofileread+174> 0xffffff8074ab3ef0 0xffffff8026d76762 <read_nocancel+130> 0xffffff8074ab3f50 0xffffff8026de16aa <unix_syscall64+522> 0xffffff8074ab3fb0 0xffffff8026ace9c3 <hndl_unix_scall64+19> stackbottom=0xffffff8074ab3fb0 thread thread_id processor pri io_policy state wait_queue wait_event 0xffffff802f4a1578 0x3c9 0xffffff80270bfc28 44 R Thread Name: com.apple.terminal.tty-io continuation=0xffffff8026ab23eb <thread_exception_return>
Comments
Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!