Opened 12 years ago

Closed 11 years ago

#2030 closed bug (fixed)

Dead Beef in Address Space Area List

Reported by: bonefish Owned by: axeld
Priority: critical Milestone: R1/alpha1
Component: System/Kernel Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

hrev24809, VMware, during boot phase

vm_soft_fault: va 0xdeadbef3 not covered by area in address space
vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0xdeadbef3, ip 0x80062857, write 0, user 0, thread 0x65
PANIC: vm_page_fault: unhandled page fault in kernel space at 0xdeadbef3, ip 0x80062857

Welcome to Kernel Debugging Land...
Running on CPU 0
kdebug> sc
stack trace for thread 101 "TrackerTaskLoop"
    kernel stack: 0x9f34d000 to 0x9f351000
      user stack: 0x70000000 to 0x70040000
frame            caller     <image>:function + offset
9f350a74 (+  52) 8008ab7f   <kernel>:invoke_debugger_command + 0x00cf
9f350aa8 (+  64) 8008b920   <kernel>:_ParseCommand__16ExpressionParserRi + 0x01f8
9f350ae8 (+  48) 8008b312   <kernel>:EvaluateCommand__16ExpressionParserPCcRi + 0x01de
9f350b18 (+ 228) 8008ca34   <kernel>:evaluate_debug_command + 0x0088
9f350bfc (+  64) 800896c2   <kernel>:kernel_debugger_loop__Fv + 0x017a
9f350c3c (+  48) 8008a36d   <kernel>:kernel_debugger + 0x010d
9f350c6c (+ 192) 8008a255   <kernel>:panic + 0x0029
9f350d2c (+  64) 800617b7   <kernel>:vm_page_fault + 0x00ab
9f350d6c (+  64) 80098ee5   <kernel>:page_fault_exception + 0x00b1
9f350dac (+  12) 8009c69d   <kernel>:int_bottom + 0x001d (nearest)
iframe at 0x9f350db8 (end = 0x9f350e10)
 eax 0xc18fff       ebx 0x90c48840      ecx 0x7003e000   edx 0xdeadbeef
 esi 0x9f350f14     edi 0x7003ef5c      ebp 0x9f350e0c   esp 0x9f350dec
 eip 0x80062857  eflags 0x10282
 vector: 0xe, error code: 0x0
9f350db8 (+  84) 80062857   <kernel>:vm_area_lookup + 0x002f
9f350e0c (+ 272) 800619f2   <kernel>:vm_soft_fault__FUlbT1 + 0x0092
9f350f1c (+  64) 8006173d   <kernel>:vm_page_fault + 0x0031
9f350f5c (+  64) 80098ee5   <kernel>:page_fault_exception + 0x00b1
9f350f9c (+  12) 8009c706   <kernel>:int_bottom_user + 0x005a (nearest)
iframe at 0x9f350fa8 (end = 0x9f351000)
 eax 0x4556e0       ebx 0x76f9f4        ecx 0xffffffff   edx 0x7003f568
 esi 0x7003f568     edi 0x7003f67c      ebp 0x7003f52c   esp 0x9f350fdc
 eip 0x725ac9    eflags 0x10206    user esp 0x7003ef60
 vector: 0xe, error code: 0x6
9f350fa8 (+   0) 00725ac9   <libroot.so>:_IO_vfprintf + 0x0009
7003f52c (+ 288) 0071804c   <libroot.so>:_IO_vsnprintf + 0x007c
7003f64c (+1072) 006e8f04   <libroot.so>:ktrace_vprintf + 0x0030
7003fa7c (+  48) 006e8ecb   <libroot.so>:ktrace_printf + 0x0023
7003faac (+ 160) 002ee259   <libbe.so>:_SendMessage__C8BMessagelllxbR10BMessenger + 0x03b1
7003fb4c (+ 144) 002ee59c   <libbe.so>:_SendMessage__C8BMessagelllP8BMessagexx + 0x01ac
7003fbdc (+  80) 0030b96f   <libbe.so>:SendMessage__CQ28BMessage7PrivatelllP8BMessagexx + 0x0043
7003fc2c (+  80) 002f575c   <libbe.so>:SendMessage__C10BMessengerP8BMessageT1xx + 0x0070
7003fc7c (+ 208) 002f91b0   <libbe.so>:GetAppInfo__C7BRosterPCcP8app_info + 0x00bc
7003fd4c (+ 320) 002f58b3   <libbe.so>:_InitData__10BMessengerPCclPl + 0x005b
7003fe8c (+  48) 002f4fa1   <libbe.so>:__10BMessengerPCclPl + 0x003d
7003febc (+  96) 005f712b   <libtracker.so>:Preload__Q28BPrivate13NodePreloader + 0x007b
7003ff1c (+  48) 005f7436   <libtracker.so>:__cl__Q28BPrivatet25PlainMemberFunctionObject1ZQ28BPrivate13NodePreloader + 0x006a
7003ff4c (+  48) 006421f3   <libtracker.so>:Run__Q28BPrivate6Thread + 0x002b
7003ff7c (+  48) 00642038   <libtracker.so>:RunBinder__Q28BPrivate12SimpleThreadPv + 0x0028
7003ffac (+  48) 006ecc40   <libroot.so>:_get_next_team_info + 0x005c (nearest)
7003ffdc (+   0) 7003ffec
[*** READ/WRITE FAULT ***]

The faulting instruction is the "if (area->id == RESERVED_AREA_ID)". The address space lock looked good (sem count 1023). No other Tracker threads were in a related part of the kernel at the time (only in syscalls like port_buffer_size(), and snooze()).

Smells like a rare race condition. A review of the address space locking might turn something up.

Change History (4)

comment:1 by stippi, 12 years ago

Priority: normalhigh

Shouldn't this one have a higher priority?

comment:2 by axeld, 11 years ago

Priority: highcritical

I just had something similar with hrev29585: while following Christian Packmann's description to enter KDL using ShowImage (by constantly zooming the image in and out), the address space's area list was messed up and contained a 0xdeadbeef entry.

comment:3 by axeld, 11 years ago

Status: newassigned

I'm on it.

comment:4 by axeld, 11 years ago

Resolution: fixed
Status: assignedclosed

Fixed in hrev29605.

Note: See TracTickets for help on using tickets.