#5489: PANIC: vm_page_fault: unhandled page fault in kernel at 0x70616d6d, ip 0x800d2723 --------------------------------------+------------------------------------- Reporter: aldeck | Owner: axeld Type: bug | Status: new Priority: normal | Milestone: R1 Component: Network & Internet/Stack | Version: R1/Development Keywords: | Blockedby: Platform: All | Blocking: --------------------------------------+------------------------------------- Changes (by bonefish): * component: System/Kernel => Network & Internet/Stack Comment: Following Axel's hint to reproduce the bug (copy several GB of files over network), I tried a {{{scp -r localhost:... ...}}} with my mp3 collection and reliably run into something like the following very quickly: {{{ PANIC: vm_page_fault: unhandled page fault in kernel space at 0x4, ip 0x800c6e28 Welcome to Kernel Debugging Land... Thread 466 "sshd" running on CPU 2 kdebug> bt stack trace for thread 466 "sshd" kernel stack: 0x822a1000 to 0x822a5000 user stack: 0x7efef000 to 0x7ffef000 frame caller <image>:function + offset 0 822a49e8 (+ 32) 800724f5 <kernel_x86> invoke_command_trampoline(void*: 0x822a4a68) + 0x0015 1 822a4a08 (+ 12) 800e74e0 <kernel_x86>:arch_debug_call_with_fault_handler + 0x001b 2 822a4a14 (+ 48) 800703a2 <kernel_x86>:debug_call_with_fault_handler + 0x0051 3 822a4a44 (+ 64) 80072872 <kernel_x86>:invoke_debugger_command + 0x00bb 4 822a4a84 (+ 48) 8007298f <kernel_x86> invoke_pipe_segment(debugger_command_pipe*: 0x8013e9a2, int32: 0, char*: NULL) + 0x0083 5 822a4ab4 (+ 32) 80072a57 <kernel_x86>:invoke_debugger_command_pipe + 0x008b 6 822a4ad4 (+ 128) 800767e2 <kernel_x86> ExpressionParser<0x822a4ba4>::_ParseCommandPipe(int&: 0x822a4ba0) + 0x0aae 7 822a4b54 (+ 48) 80078fab <kernel_x86> ExpressionParser<0x822a4ba4>::EvaluateCommand(char const*: 0x8013e9a0 "bt", int&: 0x822a4ba0) + 0x06df 8 822a4b84 (+ 192) 80079124 <kernel_x86>:evaluate_debug_command + 0x0084 9 822a4c44 (+ 64) 8007106e <kernel_x86> kernel_debugger_loop(char const*: 0x2 "<???>", char const*: 0x8013296b "PANIC: ", char*: 0x822a4cb4, int32:c 10 822a4c84 (+ 48) 80071232 <kernel_x86> kernel_debugger_internal(char const*: 0x2 "<???>", char const*: 0x2 "<???>", char*: 0x822a4cd4, int32: -214c 11 822a4cb4 (+ 32) 80071415 <kernel_x86>:panic + 0x0023 12 822a4cd4 (+ 64) 800cc2f1 <kernel_x86>:vm_page_fault + 0x00f7 13 822a4d14 (+ 80) 800e2c70 <kernel_x86> page_fault_exception(iframe*: 0x822a4d70) + 0x0171 14 822a4d64 (+ 12) 800e788d <kernel_x86>:int_bottom + 0x003d kernel iframe at 0x822a4d70 (end = 0x822a4dc0) eax 0x82fdd018 ebx 0x82fdd018 ecx 0x0 edx 0x828c001c esi 0x828ca7a8 edi 0x828ca780 ebp 0x822a4dc0 esp 0x822a4da4 eip 0x800c6e28 eflags 0x210202 vector: 0xe, error code: 0x2 15 822a4d70 (+ 80) 800c6e28 <kernel_x86>:list_remove_link + 0x000b 16 822a4dc0 (+ 20) 800c6f2f <kernel_x86>:list_remove_head_item + 0x0019 17 822a4dd4 (+ 48) 8101a78c </boot/system/add-ons/kernel/network/stack> free_buffer(net_buffer*: 0x828ca780) + 0x0024 18 822a4e04 (+ 128) 8101c0ee </boot/system/add-ons/kernel/network/stack> socket_send(net_socket*: 0xce554000, msghdr*: NULL, void const*: 0x183eca1e,0 19 822a4e84 (+ 48) 81023447 </boot/system/add-ons/kernel/network/stack> stack_interface_send(net_socket*: 0xce554000, void const*: 0x183e4a1e, uint3d 20 822a4eb4 (+ 32) 800a6546 <kernel_x86> socket_write(file_descriptor*: 0xd095f320, int64: 86363000, void const*: 0x183e4a1e, unsigned long*: 0x822af 21 822a4ed4 (+ 80) 800a0e9f <kernel_x86> common_user_io(int32: 406735390, int64: 4295012218, void*: 0xd0376800, uint32: 0x822a4fa8, true) + 0x00ff 22 822a4f24 (+ 32) 800a0f3b <kernel_x86>:_user_write + 0x001c 23 822a4f44 (+ 100) 800e7ad1 <kernel_x86>:handle_syscall + 0x00be user iframe at 0x822a4fa8 (end = 0x822a5000) eax 0x85 ebx 0x4b758c ecx 0x7ffeec20 edx 0xffff0114 esi 0x0 edi 0x183e4a1e ebp 0x7ffeec5c esp 0x822a4fdc eip 0xffff0114 eflags 0x200203 user esp 0x7ffeec20 vector: 0x63, error code: 0x0 24 822a4fa8 (+ 0) ffff0114 <commpage>:commpage_syscall + 0x0004 25 7ffeec5c (+ 48) 0022d78d <sshd>:roaming_write + 0x0029 26 7ffeec8c (+ 48) 0023d92f <sshd>:packet_write_poll + 0x0067 27 7ffeecbc (+ 80) 00217732 <sshd>:dump_config (nearest) + 0x1222 28 7ffeed0c (+ 80) 002180ae <sshd>:server_loop2 + 0x00fa 29 7ffeed5c (+ 48) 0022044b <sshd>:session_setup_x11fwd (nearest) + 0x028f 30 7ffeed8c (+ 48) 0021bf1a <sshd>:do_authenticated + 0x0062 31 7ffeedbc (+ 432) 00211482 <sshd>:main + 0x18b6 32 7ffeef6c (+ 48) 0020db3f <sshd>:_start + 0x005b 33 7ffeef9c (+ 64) 00105367 </boot/system/runtime_loader@0x00100000>:unknown + 0x5367 34 7ffeefdc (+ 0) 7ffeefec 5290:sshd_main_stack@0x7efef000 + 0xffffec kdebug> call 16 -1 thread 466, sshd 822a4dc0 800c6f2f <kernel_x86>:list_remove_head_item(0x828ca7a8) kdebug> dw 0x828ca7a8 [0x828ca7a8] .�...�.......... 82fdd018 82fdd018 00000000 80f00000 kdebug> dw 0x82fdd018 [0x82fdd018] .........�...�.. 00000000 828c001c 82fdd000 82fdd000 kdebug> traced 0 -2 -1 #0x82fdd000 1878673. [ 466] 140281514: object cache alloc: cache: 0x828a6dc0, flags: 0x0 -> object: 0x82fdd000 1878688. [ 466] 140281522: object cache free: cache: 0x828a6dc0, object: 0x82fdd000 printed 2 entries within range 1878673 to 1879633 (961 of 1879633 total, 1879516 ever) }}} So obviously net buffer data nodes are used after they have been freed, which would definitely explain the memory overwriting problems. I haven't checked, but I doubt that disabling the object depots would have any effect (other than speeding up the crash). So there might be different issues. -- Ticket URL: <http://dev.haiku-os.org/ticket/5489#comment:6> Haiku <http://dev.haiku-os.org> Haiku - the operating system.