Opened 7 years ago
Closed 7 years ago
#13969 closed bug (invalid)
bfs_tools/recover crashes
Reported by: | Anarchos | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | File Systems | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | x86 |
Description
Revision hrev51727. See logs attached.
Attachments (2)
Change History (3)
by , 7 years ago
Attachment: | recover-778-debug-20-01-2018-13-33-51.report added |
---|
by , 7 years ago
Attachment: | recover-1073-debug-20-01-2018-13-47-34.report added |
---|
comment:1 by , 7 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Note:
See TracTickets
for help on using tickets.
This just means that the guarded heap has run out of memory, or more likely address space, to allocate a new area. The guarded heap works by padding each allocation with an unmapped page following it, so that out of bound access triggers a fault. For this to work the allocation has to be done at a page boundary, so each allocation requires at least one page of memory and at least two pages of address space.
Since recover uses a lot of memory even without a debug heap, adding debugging features makes it consume huge amounts of memory/address space. The 32 bit address space is too constraint to allow for this (even if the amount of available pages of memory would be larger/sufficient using PAE).
You should try using a 64 bit version of Haiku to see if the larger address space makes it work. It may still fail due to exhausting memory (which may be worked around using virtual memory).
In either case, this is not a bug. The debugger call simply tells that it's not possible to use the desired debugging features in the given situation due to resource constraints. Low resource messages in the syslog may hint at which of the resources was exhausted.