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)

recover-778-debug-20-01-2018-13-33-51.report (93.8 KB ) - added by Anarchos 7 years ago.
recover-1073-debug-20-01-2018-13-47-34.report (93.6 KB ) - added by Anarchos 7 years ago.

Download all attachments as: .zip

Change History (3)

comment:1 by mmlr, 7 years ago

Resolution: invalid
Status: newclosed

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.

Note: See TracTickets for help on using tickets.