Opened 19 years ago
Last modified 17 years ago
#417 closed bug
[kernel] PANIC: vm_page_fault... — at Version 4
Reported by: | diver | Owned by: | axeld |
---|---|---|---|
Priority: | blocker | Milestone: | R1 |
Component: | System/Kernel | Version: | |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description (last modified by )
You could crash haiku if you go to the /boot/beos/system/lib select all and press enter several times. Sometims it's just lib, that crash. I know i shouldn't launch libs, but this may uncover some deeper bugs. back traces will follow. Tested under vmware with rev17009.
Change History (8)
by , 19 years ago
comment:1 by , 19 years ago
I can't reproduce this bug. I had a deviation of this (an area/vm_cache with wrong ref_count) some time ago, but I couldn't reproduce this either. IOW there is some hard to track bug in the reference counting of areas or vm_caches.
I've changed the runtime_loader's test_executable() function to choke on libraries already, so they are no longer executed at all.
comment:2 by , 19 years ago
(In reply to comment #3)
I can't reproduce this bug. I had a deviation of this (an area/vm_cache with wrong ref_count) some time ago, but I couldn't reproduce this either. IOW
there
is some hard to track bug in the reference counting of areas or vm_caches.
I can reproduce it if i go to /boot/beos/bin folder, select all and press enter several(3-5) times. Could you investigate this, Axel? Tested with rev17117 under vmware. P.S. Shouldn't tracker show alert window in such situations, smth like this (You are trying top open ##files, are you sure?)
comment:3 by , 19 years ago
Summary: | PANIC: vm_page_fault... → [kernel] PANIC: vm_page_fault... |
---|
comment:4 by , 18 years ago
Description: | modified (diff) |
---|---|
Platform: | → All |
Priority: | normal → blocker |
back trace in kdl