Opened 9 years ago

Closed 9 years ago

#5413 closed bug (fixed)

PANIC: page 0x821e7918 has mapping for area 0x86259a00 (0x7ffef000), but has no page table entry

Reported by: anevilyak Owned by: bonefish
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: Cc: Jens.Arm@…
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

While compiling on hrev35488 w/ Axel's BFS and block cache changes reverted, I ran into this panic. Info as follows:

stack trace for thread 2034 "jam"
    kernel stack: 0x817f2000 to 0x817f6000
      user stack: 0x7efef000 to 0x7ffef000
frame               caller     <image>:function + offset
 0 817f56e8 (+  32) 80068d3d   <kernel_x86> invoke_command_trampoline(void*: 0x817f5768) + 0x0015
 1 817f5708 (+  12) 800d75e8   <kernel_x86>:arch_debug_call_with_fault_handler + 0x001b
 2 817f5714 (+  48) 80066c02   <kernel_x86>:debug_call_with_fault_handler + 0x0051
 3 817f5744 (+  64) 80069030   <kernel_x86>:invoke_debugger_command + 0x00bb
 4 817f5784 (+  48) 8006914d   <kernel_x86> invoke_pipe_segment(debugger_command_pipe*: 0x80125da2, int32: 0, char*: NULL) + 0x0083
 5 817f57b4 (+  32) 80069215   <kernel_x86>:invoke_debugger_command_pipe + 0x008b
 6 817f57d4 (+ 128) 8006d066   <kernel_x86> ExpressionParser<0x817f58a4>::_ParseCommandPipe(int&: 0x817f58a0) + 0x0aae
 7 817f5854 (+  48) 8006f82f   <kernel_x86> ExpressionParser<0x817f58a4>::EvaluateCommand(char const*: 0x80125da0 "bt", int&: 0x817f58a0) + 0x06df
 8 817f5884 (+ 192) 8006f9a8   <kernel_x86>:evaluate_debug_command + 0x0084
 9 817f5944 (+  96) 800679d5   <kernel_x86> kernel_debugger_internal(char const*: 0x8604b7fc "' Õ'      ", int32: -2122360368) + 0x039a
10 817f59a4 (+  16) 80067b2b   <kernel_x86>:kernel_debugger + 0x0019
11 817f59b4 (+ 160) 80067bed   <kernel_x86>:panic + 0x002a
12 817f5a54 (+  96) 800d6d33   <kernel_x86> X86VMTranslationMap<0x864239f0>::UnmapArea(VMArea*: 0x86259a00, false, true) + 0x01f1
13 817f5ab4 (+  48) 800be432   <kernel_x86> delete_area(VMAddressSpace*: 0x85fb8e60, VMArea*: 0x86420540, true) + 0x00a6
14 817f5ae4 (+  32) 800be56b   <kernel_x86>:vm_delete_areas + 0x004c
15 817f5b04 (+1088) 800594e6   <kernel_x86>:_user_exec + 0x0149
16 817f5f44 (+ 100) 800d7bc2   <kernel_x86>:handle_syscall + 0x00af
user iframe at 0x817f5fa8 (end = 0x817f6000)
 eax 0x26           ebx 0x2e94ac        ecx 0x7ffedde0   edx 0xffff0114
 esi 0x7ffef008     edi 0x0             ebp 0x7ffedf2c   esp 0x817f5fdc
 eip 0xffff0114  eflags 0x203      user esp 0x7ffedde0
 vector: 0x63, error code: 0x0
17 817f5fa8 (+   0) ffff0114   <commpage>:commpage_syscall + 0x0004
7ffedf2c -- read fault
kdebug> page 0x821e7918
PAGE: 0x821e7918
queue_next,prev: 0x823b0420, 0x823c9920
physical_number: 0xc307
cache:           0x85fefca0
cache_offset:    4096
cache_next:      0x00000000
state:           active
wired_count:     0
usage_count:     0
busy:            0
busy_writing:    0
accessed:        1
modified:        0
area mappings:
kdebug> area 0x86259a00
AREA: 0x8575bba0
name:           'slab area'
owner:          0x1
id:             0x13aa
base:           0x86000000
size:           0x800000
protection:     0x10
wiring:         0x1
memory_type:    0x0
cache:          0x847d6e70
cache_type:     null
cache_offset:   0x0
cache_next:     0x00000000
cache_prev:     0x00000000
page mappings:  0

Possibly related, possibly not, I also notice that with revisions since the page writer changes, after spending some time doing large builds such as Haiku or Webkit, gcc starts randomly segfaulting in completely unpredictable places. Rebooting fixes it though, at least temporarily. Uncertain if it's related or not, but it's at least not a problem I can encounter with an earlier kernel.

Change History (12)

comment:1 Changed 9 years ago by anevilyak

To be exact, I don't encounter this problem with an hrev35294 kernel.

comment:2 Changed 9 years ago by anevilyak

Owner: changed from axeld to bonefish
Status: newassigned

comment:3 Changed 9 years ago by jahaiku

Cc: Jens.Arm@… added

comment:4 Changed 9 years ago by bonefish

Unfortunately you printed the wrong area. The "area" command resolves the given address to the area it is located in and prints that area. If you have a pointer to a VMArea structure the "area address <address>" syntax has to be used. It would also be interesting to learn something about the involved caches -- i.e. the one of the page, the one of the area (if different), and the corresponding "cache_tree".

Apparently you have enabled USE_SLAB_ALLOCATOR_FOR_MALLOC. Is the problem reproducible when disabling it?

Also, since I neither encounter problems with 4 GB memory on real hardware, nor with emulated low-memory setups, it would be interesting what system you're testing on, and if you have a test you can more or less reliably reproduce the problem.

comment:5 in reply to:  4 ; Changed 9 years ago by anevilyak

Replying to bonefish:

Unfortunately you printed the wrong area. The "area" command resolves the given address to the area it is located in and prints that area. If you have a pointer to a VMArea structure the "area address <address>" syntax has to be used. It would also be interesting to learn something about the involved caches -- i.e. the one of the page, the one of the area (if different), and the corresponding "cache_tree".

Whoops. Will remember that if/when I encounter it again.

Apparently you have enabled USE_SLAB_ALLOCATOR_FOR_MALLOC. Is the problem reproducible when disabling it?

Will try.

Also, since I neither encounter problems with 4 GB memory on real hardware, nor with emulated low-memory setups, it would be interesting what system you're testing on, and if you have a test you can more or less reliably reproduce the problem.

The panic I've only run into once so far. The segfaults during build happen fairly reliably with the haiku tree for me (after building for long enough). In any case, 1GB of RAM w/ 200MB trace buffer, dual core Athlon64.

comment:6 in reply to:  5 Changed 9 years ago by bonefish

Status: assignedin-progress

Replying to anevilyak:

Replying to bonefish:

Also, since I neither encounter problems with 4 GB memory on real hardware, nor with emulated low-memory setups, it would be interesting what system you're testing on, and if you have a test you can more or less reliably reproduce the problem.

The panic I've only run into once so far. The segfaults during build happen fairly reliably with the haiku tree for me (after building for long enough). In any case, 1GB of RAM w/ 200MB trace buffer, dual core Athlon64.

Indeed the first Haiku image build run I tried with 1 GB RAM turned up a problem, as commented in #5374. I guess it's likely that both issues have the same cause, which could be modified or mapped pages being moved erroneously to the "cached" queue.

comment:7 Changed 9 years ago by bonefish

Status: in-progressassigned

hrev35500 fixes #5374, but the fixed problem only explains modified pages ending up in the cached queue, not mapped ones. I haven't been able to reproduce the bug with this revision either, though. I've added a few new asserts. Maybe they will turn something up.

comment:8 Changed 9 years ago by anevilyak

I've at least not managed to reproduce either problem with the webkit tree so far (still using slab allocator for malloc + hrev35502 w/ Axel's block cache changes reverted). Trying the haiku tree next, will let you know.

comment:9 Changed 9 years ago by anevilyak

Can't reproduce it any more with the haiku tree either. I'd say close for now and I'll reopen if I do run into it another time, if there's indeed no way for your other fixes to explain this issue disappearing.

comment:10 Changed 9 years ago by bonefish

Resolution: fixed
Status: assignedclosed

OK, closing for the time being.

comment:11 Changed 9 years ago by anevilyak

Resolution: fixed
Status: closedreopened

I just hit this one again with hrev35681. Data as follows:

PANIC: page 0x82052580 has mapping for area 0x85ee9780 (0x9bf000), but has no page table entry
kdebug> bt
stack trace for thread 2145 "cc1"
    kernel stack: 0x817a5000 to 0x817a9000
      user stack: 0x7efed000 to 0x7ffed000
frame               caller     <image>:function + offset
 0 817a8968 (+  32) 8006a3e9   <kernel_x86> invoke_command_trampoline(void*: 0x817a89e8) + 0x0015
 1 817a8988 (+  12) 800d8fa4   <kernel_x86>:arch_debug_call_with_fault_handler + 0x001b
 2 817a8994 (+  48) 80068266   <kernel_x86>:debug_call_with_fault_handler + 0x0051
 3 817a89c4 (+  64) 8006a6dc   <kernel_x86>:invoke_debugger_command + 0x00bb
 4 817a8a04 (+  48) 8006a7f9   <kernel_x86> invoke_pipe_segment(debugger_command_pipe*: 0x80128da2, int32: 0, char*: NULL) + 0x0083
 5 817a8a34 (+  32) 8006a8c1   <kernel_x86>:invoke_debugger_command_pipe + 0x008b
 6 817a8a54 (+ 128) 8006e712   <kernel_x86> ExpressionParser<0x817a8b24>::_ParseCommandPipe(int&: 0x817a8b20) + 0x0aae
 7 817a8ad4 (+  48) 80070edb   <kernel_x86> ExpressionParser<0x817a8b24>::EvaluateCommand(char const*: 0x80128da0 "bt", int&: 0x817a8b20) + 0x06df
 8 817a8b04 (+ 192) 80071054   <kernel_x86>:evaluate_debug_command + 0x0084
 9 817a8bc4 (+  64) 80068f32   <kernel_x86> kernel_debugger_loop(char const*: 0x0 "<NULL>", char const*: 0x80112c73 "PANIC: ", char*: 0x817a8c34, int32: -2147053352) + 0x026c
10 817a8c04 (+  48) 800690f6   <kernel_x86> kernel_debugger_internal(char const*: 0x0 "<NULL>", char const*: 0x97a000 "<???>", char*: 0x817a8c54, int32: -2147052858) + 0x011c
11 817a8c34 (+  32) 800692d9   <kernel_x86>:panic + 0x0023
12 817a8c54 (+  96) 800d86ef   <kernel_x86> X86VMTranslationMap<0x85b1ac30>::UnmapArea(VMArea*: 0x85ee9780, true, true) + 0x01f1
13 817a8cb4 (+  48) 800c0194   <kernel_x86> delete_area(VMAddressSpace*: 0x83b63d10, VMArea*: 0x246, true) + 0x00a6
14 817a8ce4 (+  32) 800c02cd   <kernel_x86>:vm_delete_areas + 0x004c
15 817a8d04 (+  32) 800c8552   <kernel_x86> VMAddressSpace<0x85614540>::RemoveAndPut() + 0x002e
16 817a8d24 (+  48) 8005d22c   <kernel_x86>:team_delete_team + 0x0152
17 817a8d54 (+ 352) 8006095a   <kernel_x86>:thread_exit + 0x03ab
18 817a8eb4 (+  96) 800556d0   <kernel_x86>:handle_signals + 0x0457
19 817a8f14 (+  48) 8006055d   <kernel_x86>:thread_at_kernel_exit + 0x005f
20 817a8f44 (+ 100) 800d965b   <kernel_x86>:kernel_exit_handle_signals + 0x0006
user iframe at 0x817a8fa8 (end = 0x817a9000)
 eax 0x0            ebx 0xa238a8        ecx 0x7ffecf50   edx 0x0
 esi 0x7ffed538     edi 0x7ffed74c      ebp 0x7ffecf6c   esp 0x817a8fdc
 eip 0xffff0114  eflags 0x202      user esp 0x7ffecf50
 vector: 0x63, error code: 0x0
21 817a8fa8 (+   0) ffff0114   <commpage>:commpage_syscall + 0x0004
22 7ffecf6c (+  96) 002c224b
23 7ffecfcc (+   0) 0020a71c
00000001 -- read fault
kdebug> area address 0x85ee9780
AREA: 0x85ee9780
name:           'libroot.so_seg0ro'
owner:          0x861
id:             0x10b20
base:           0x95c000
size:           0xc4000
protection:     0x15
wiring:         0x0
memory_type:    0x0
cache:          0x85d39c28
cache_type:     vnode
cache_offset:   0x0
cache_next:     0x00000000
cache_prev:     0x00000000
page mappings:  0
kdebug> cache 0x85d39c28
CACHE 0x85d39c28:
  ref_count:    2
  source:       0x839a9e98
  type:         RAM
  virtual_base: 0x0
  virtual_end:  0xc4000
  temporary:    1
  scan_skip:    0
  lock:         0x85d39c74
  areas:
    area 0x10b20, libroot.so_seg0ro
        base_addr:  0x95c000, size: 0xc4000
        protection: 0x15
        owner:      0x861
  consumers:
  pages:
        6 in cache
kdebug> cache_tree 0x85d39c28
0x839a9e98
  0x839a9718
  0x839a9198
  0x839c23a8
  0x839c24a8
  0x839a9318
  0x839b62b8
  0x839b6238
  0x839bc4b0
  0x83b28e50
  0x83b44f60
  0x83b44060
  0x83b4af00
  0x83b2ff58
  0x83b28050
  0x83b65b18
  0x83b4de80
  0x83b28ed0
  0x83b62190
  0x83b60a08
  0x83b60988
  0x83b67520
  0x83b674a0
  0x83b6e2a8
  0x83b70630
  0x83b62110
  0x83b60788
  0x83b72138
  0x83b720b8
  0x843900b0
  0x83dc6f20
  0x84070890
  0x85611838
  0x85edf690
  0x85d39c28 <--
  0x8561ed48
  0x843be6e0
  0x85ee70a0
  0x8601ee40
kdebug> page 0x82052580
PAGE: 0x82052580
queue_next,prev: 0x82052350, 0x82053048
physical_number: 0x20f0
cache:           0x839a9e98
cache_offset:    99
cache_next:      0x820525a8
state:           inactive
wired_count:     0
usage_count:     0
busy:            0
busy_writing:    0
accessed:        1
modified:        0
area mappings:
  0x83dea500 (4690)
  0x83b71a50 (4632)
  0x839b77d0 (1807)
  0x839c0f50 (1669)
  0x83b69190 (3076)
  0x83b35910 (3185)
  0x839c00a0 (3193)
  0x83b47370 (2645)
  0x83b73320 (3290)
  0x839b7dc0 (2547)
  0x83b47e60 (2733)
  0x839b1b40 (1838)
kdebug> cache 0x839a9e98
CACHE 0x839a9e98:
  ref_count:    41
  source:       0x00000000
  type:         vnode
  virtual_base: 0x0
  virtual_end:  0x12ea83
  temporary:    0
  scan_skip:    0
  lock:         0x839a9ee4
  areas:
  consumers:
        0x839a9718
        0x839a9198
        0x839c23a8
        0x839c24a8
        0x839a9318
        0x839b62b8
        0x839b6238
        0x839bc4b0
        0x83b28e50
        0x83b44f60
        0x83b44060
        0x83b4af00
        0x83b2ff58
        0x83b28050
        0x83b65b18
        0x83b4de80
        0x83b28ed0
        0x83b62190
        0x83b60a08
        0x83b60988
        0x83b67520
        0x83b674a0
        0x83b6e2a8
        0x83b70630
        0x83b62110
        0x83b60788
        0x83b72138
        0x83b720b8
        0x843900b0
        0x83dc6f20
        0x84070890
        0x85611838
        0x85edf690
        0x85d39c28
        0x8561ed48
        0x843be6e0
        0x85ee70a0
        0x8601ee40
  pages:
        202 in cache
kdebug> cache_tree 0x839a9e98
0x839a9e98 <--
  0x839a9718
  0x839a9198
  0x839c23a8
  0x839c24a8
  0x839a9318
  0x839b62b8
  0x839b6238
  0x839bc4b0
  0x83b28e50
  0x83b44f60
  0x83b44060
  0x83b4af00
  0x83b2ff58
  0x83b28050
  0x83b65b18
  0x83b4de80
  0x83b28ed0
  0x83b62190
  0x83b60a08
  0x83b60988
  0x83b67520
  0x83b674a0
  0x83b6e2a8
  0x83b70630
  0x83b62110
  0x83b60788
  0x83b72138
  0x83b720b8
  0x843900b0
  0x83dc6f20
  0x84070890
  0x85611838
  0x85edf690
  0x85d39c28
  0x8561ed48
  0x843be6e0
  0x85ee70a0
  0x8601ee40
kdebug>

comment:12 Changed 9 years ago by bonefish

Resolution: fixed
Status: reopenedclosed

Probably fixed in hrev36523. Please reopen, if encountered again.

Note: See TracTickets for help on using tickets.