[haiku-bugs] Re: [Haiku] #5489: PANIC: vm_page_fault: unhandled page fault in kernel at 0x70616d6d, ip 0x800d2723

From: "bonefish" <trac@xxxxxxxxxxxx>
Date: Thu, 04 Mar 2010 00:10:00 -0000
#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.
[haiku-bugs] Re: [Haiku] #5489: PANIC: vm_page_fault: unhandled page fault in kernel at 0x70616d6d, ip 0x800d2723

Other related posts:
