asserts fail in vm_page.cpp

[jonas.kirilla]

The asserts at ​http://dev.haiku-os.org/browser/haiku/trunk/src/system/kernel/vm/vm_page.cpp#L1927 and ​http://dev.haiku-os.org/browser/haiku/trunk/src/system/kernel/vm/vm_page.cpp#L1928 fail now and then in prolonged use of Haiku with heavy networking.

This is on a uniprocessor. All of the resulting KDLs have been continuable seemingly without ill effect.

[jonas.kirilla]

Revision hrev35516.

[bonefish]

Stack traces would be extraordinarily helpful. If the vm_page address is available (should be in the stack trace, though on gcc 4 it will probably be incorrect), the output of "page -m <address>" would be interesting. Furthermore the cache printed for the page could be fed to the "cache" and "cache_tree" commands which might also turn up interesting information.

[idefix]

I also encountered this, but it happened while Haiku hrev35516 was booting:

PANIC: ASSERT FAILED (/storage/Build-O-Matic/nightly-uploader/haiku/haiku/src/system/kernel/vm/vm_page.cpp:1928): page->wired_count ==
Welcome to Kernel Debugging Land...
Thread 92 "midi_server" running on CPU 0
kdebug> bt
stack trace for thread 92 "midi_server"
    kernel stack: 0x8023a000 to 0x8023e000
      user stack: 0x7efef000 to 0x7ffef000
frame               caller     <image>:function + offset
 0 8023d930 (+  48) 8006fe68   <kernel_x86> invoke_command_trampoline([34m0x8023d9c8[0m) + 0x001c
 1 8023d960 (+  12) 800f951c   <kernel_x86>:arch_debug_call_with_fault_handler + 0x001b
 2 8023d96c (+  48) 8006f048   <kernel_x86>:debug_call_with_fault_handler + 0x0060
 3 8023d99c (+  64) 800700c1   <kernel_x86>:invoke_debugger_command + 0x00b9
 4 8023d9dc (+  64) 8006feed   <kernel_x86> invoke_pipe_segment(debugger_command_pipe*: [34m0x81e9c030[0m, int32: [34m0[0m, [34m0x0[0m [31m"<NULL>"[0m) + 0x0079
 5 8023da1c (+  64) 8007022c   <kernel_x86>:invoke_debugger_command_pipe + 0x009c
 6 8023da5c (+  48) 80071be4   <kernel_x86> ExpressionParser<[32m0x8023db0c[0m>::_ParseCommandPipe([34m0x8023db08[0m) + 0x0234
 7 8023da8c (+  64) 8007101e   <kernel_x86> ExpressionParser<[32m0x8023db0c[0m>::EvaluateCommand([34m0x8014bce0[0m [36m"bt"[0m, [34m0x8023db08[0m) + 0x02ba
 8 8023dacc (+ 224) 80072ff8   <kernel_x86>:evaluate_debug_command + 0x0080
 9 8023dbac (+  64) 8006db52   <kernel_x86> kernel_debugger_loop([34m0x8023dc8c[0m [36m"ASSERT FAILED (/storage/Build-O-Matic/nightly-uploader/haiku/haiku/src/system/kernel/vm/vm_page.cpp:1928): page->wired_count =="[0m, int32: [34m0[0m) + 0x0296
10 8023dbec (+  48) 8006dda6   <kernel_x86> kernel_debugger_internal([34m0x8023dc8c[0m [36m"ASSERT FAILED (/storage/Build-O-Matic/nightly-uploader/haiku/haiku/src/system/kernel/vm/vm_page.cpp:1928): page->wired_count =="[0m, int32: [34m0[0m) + 0x0042
11 8023dc1c (+  48) 8006f20d   <kernel_x86>:kernel_debugger + 0x001d
12 8023dc4c (+ 192) 8006f1e5   <kernel_x86>:panic + 0x0029
13 8023dd0c (+  96) 800e103d   <kernel_x86> free_cached_page(vm_page*: [34m0x81c81a88[0m, [34mfalse[0m) + 0x007d
14 8023dd6c (+ 112) 800e1366   <kernel_x86> free_cached_pages(uint32: [34m0x3[0m ([34m3[0m), [34mfalse[0m) + 0x0056
15 8023dddc (+  96) 800e2439   <kernel_x86> reserve_pages(uint32: [34m0x3[0m ([34m3[0m), int32: [34m0[0m, [34mfalse[0m) + 0x0049
16 8023de3c (+  32) 800e38ad   <kernel_x86>:vm_page_reserve_pages + 0x0025
17 8023de5c (+ 176) 800daf81   <kernel_x86> vm_soft_fault(VMAddressSpace*: [34m0x818a58e8[0m, uint32: [34m0x3c5000[0m, [34mfalse[0m, [34mtrue[0m) + 0x00a9
18 8023df0c (+  64) 800dacd4   <kernel_x86>:vm_page_fault + 0x00a8
19 8023df4c (+  80) 800f4532   <kernel_x86> page_fault_exception(iframe*: [34m0x8023dfa8[0m) + 0x017e
20 8023df9c (+  12) 800f9926   <kernel_x86>:int_bottom_user + 0x005a
user iframe at 0x8023dfa8 (end = 0x8023e000)
 eax 0x1802b120     ebx 0x47e648        ecx 0x18029180   edx 0xb6
 esi 0x1802b120     edi 0x0             ebp 0x7ffee9cc   esp 0x8023dfdc
 eip 0x3c5080    eflags 0x10213    user esp 0x7ffee970
 vector: 0xe, error code: 0x4
21 8023dfa8 (+   0) 003c5080   <libbe.so> BPrivate::Storage::ResourceFile<[32m0x18029180[0m>::_ReadInfoTableEnd([34m0x7ffeea00[0m, int32: [34m2147412508[0m) + 0x0000
22 7ffee9cc (+  80) 003c27f9   <libbe.so> BPrivate::Storage::ResourceFile<[32m0x18029180[0m>::InitContainer(BPrivate::Storage::ResourcesContainer&: [34m0x18025190[0m) + 0x0131
23 7ffeea1c (+  64) 003c6c87   <libbe.so> BResources<[32m0x18027120[0m>::SetTo(BFile*: [34m0x7ffeed00[0m, [34mfalse[0m) + 0x0123
24 7ffeea5c (+  64) 003ac2e8   <libbe.so> BAppFileInfo<[32m0x7ffeed68[0m>::SetTo(BFile*: [34m0x7ffeed00[0m) + 0x0108
25 7ffeea9c (+ 768) 002c8902   <libbe.so> BApplication<[32m0x7ffeee34[0m>::_InitData([34m0x20c3c0[0m [36m"application/x-vnd.Haiku-midi_server"[0m, [34mtrue[0m, NULL) + 0x01b6
26 7ffeed9c (+  48) 002c82c0   <libbe.so>:__12BApplicationPCc + 0x0050
27 7ffeedcc (+  64) 00207a00   <_APP_>:__13MidiServerApp + 0x0028
28 7ffeee0c (+ 368) 0020958e   <_APP_>:main + 0x0026
29 7ffeef7c (+  48) 002078b3   <_APP_>:_start + 0x005b
30 7ffeefac (+  48) 00105d72   </boot/system/runtime_loader@0x00100000>:unknown + 0x5d72
31 7ffeefdc (+   0) 7ffeefec   1505:midi_server_main_stack@0x7efef000 + 0xffffec

[anevilyak]

It looks like your backtrace is garbled a little, was this captured via serial or.. ?

[idefix]

Yes, via serial. Where is it garbled?

[anevilyak]

Example: 9 8023dbac (+ 64) 8006db52 <kernel_x86> kernel_debugger_loop([34m0x8023dc8c[0m [36m"ASSERT FAILED (/storage/Build-O-Matic/nightly-uploader/haiku/haiku/src/system/kernel/vm/vm_page.cpp:1928): page->wired_count =="[0m, int32: [34m0[0m) + 0x0296

[axeld]

I have secured some debug output from this as well; I'll add it tomorrow (photos).

[idefix]

Replying to anevilyak:

Example: 9 8023dbac (+ 64) 8006db52 <kernel_x86> kernel_debugger_loop([34m0x8023dc8c[0m [36m"ASSERT FAILED (/storage/Build-O-Matic/nightly-uploader/haiku/haiku/src/system/kernel/vm/vm_page.cpp:1928): page->wired_count =="[0m, int32: [34m0[0m) + 0x0296

Sorry, but I can't see any garble there, other than some ansi-coloring code. Without that code, that line looks fine by me:

9 8023dbac (+  64) 8006db52   <kernel_x86> kernel_debugger_loop(0x8023dc8c "ASSERT FAILED (/storage/Build-O-Matic/nightly-uploader/haiku/haiku/src/system/kernel/vm/vm_page.cpp:1928): page->wired_count ==", int32: 0) + 0x0296

[anevilyak]

You're right, I misread. Sorry for the noise, I was under the impression the color codes + accompanying assert string were in the middle of where addresses were supposed to be getting printed out.

[bonefish]

Replying to idefix:

Sorry, but I can't see any garble there, other than some ansi-coloring code. Without that code, that line looks fine by me:

It would be nice to filter the serial output through a terminal, though, since most of us prefer to see the Matrix unencoded. ;-)

[axeld]

488KB is really a bit low

[idefix]

Replying to bonefish:

Replying to idefix:

Sorry, but I can't see any garble there, other than some ansi-coloring code. Without that code, that line looks fine by me:

It would be nice to filter the serial output through a terminal, though, since most of us prefer to see the Matrix unencoded. ;-)

I would love to, but is that possible with Hyperterminal?

[bonefish]

Replying to idefix:

Replying to bonefish:

It would be nice to filter the serial output through a terminal, though, since most of us prefer to see the Matrix unencoded. ;-)

I would love to, but is that possible with Hyperterminal?

No idea, I've never used that one. As long as you can get the raw serial output, you can "cat" it in a real Terminal and copy the interpreted output.

[idefix]

Replying to bonefish:

No idea, I've never used that one. As long as you can get the raw serial output, you can "cat" it in a real Terminal and copy the interpreted output.

Thanks for the pointer. I have found ​this tip which uses sed to remove the ansi escape sequences. It works fine, so I will use that from now on.

[bonefish]

I added kernel tracing to be able to track page state transitions in hrev35538. A helpful kernel tracing configuration would include the following settings:

#define PAGE_STATE_TRACING             1
#define PAGE_STATE_TRACING_STACK_TRACE 8
#define VM_CACHE_TRACING               2

As well as a reasonable large MAX_TRACE_SIZE (100 or more). Besides the info mentioned in 2 the tracing info for the page in question would be of considerable interest:

traced --stacktrace 0 -30 -1 #<address>

I'll try to play some more with a reduced total memory size. So far I haven't been able to trigger the assert, though.

[bonefish]

Fixed in hrev35539. Just incorrect asserts as it turned out.