Opened 15 years ago
Closed 15 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: | ||
| 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 by , 15 years ago
comment:2 by , 15 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:3 by , 15 years ago
| Cc: | added |
|---|
follow-up: 5 comment:4 by , 15 years ago
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.
follow-up: 6 comment:5 by , 15 years ago
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 by , 15 years ago
| Status: | assigned → in-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 by , 15 years ago
| Status: | in-progress → assigned |
|---|
comment:8 by , 15 years ago
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 by , 15 years ago
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 by , 15 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
OK, closing for the time being.
comment:11 by , 15 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
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 by , 15 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
Probably fixed in hrev36523. Please reopen, if encountered again.
To be exact, I don't encounter this problem with an hrev35294 kernel.