Ticket #1911 (closed bug: fixed)

Opened 9 months ago

Last modified 8 months ago

PANIC: heap: huge allocation of 6292992 bytes asked!

Reported by: thorn Owned by: axeld
Priority: high Milestone: R1/alpha1
Component: File Systems/BFS Version: R1 development
Cc: Blocked By:
Platform: All Blocking:

Description

Haiku r24348 backtrace included

Attachments

panic2.PNG (48.7 kB) - added by thorn 9 months ago.
backtrace

Change History

Changed 9 months ago by thorn

backtrace

Changed 9 months ago by thorn

  • component changed from - General to File Systems/BFS

after reboot:

bfs: Replay log, disk was not correctly unmounted... run count: 11264, array max: -1, max runs: 254 bfs: Log entry has broken header! bfs: replaying log entry from 452 failed: Bad data bfs: could not initialize journal/block bitmap allocator! bfs: bfs_mount:127: Out of memory SCSI_DSK -- synchronize_cache: bfs: Remove:1680: No such file or directory bfs: Could not find value in index "size"! bfs: Remove:1680: No such file or directory bfs: Could not find value in index "last_modified"! SCSI_DSK -- synchronize_cache:

Changed 9 months ago by axeld

  • priority changed from normal to high
  • milestone changed from R1 to R1/alpha1

What size is your disk? BFS currently loads the whole block bitmap on mount to correct an eventual incorrect used block count. There is no reason why it does it this way, though.

Changed 9 months ago by thorn

I can try to repeat and send broken bfs image to you. bfs volume - 2G block size - 2048 memory - 256M

Changed 9 months ago by axeld

Okay, with that disk size, the block bitmap should be about 120K bytes large. Also, I was wrong with my original statement; BFS only allocates allocation group sized blocks, so probably 10K. Looks like your disk is seriously broken. Probably due to broken log entries. What exactly did you do with that disk before?

Changed 9 months ago by thorn

heh, it's a virtual disk image (vmdk)

Changed 8 months ago by axeld

  • status changed from new to closed
  • resolution set to fixed

I've improved BPlusTree::_SeekDown() in rr24411 to detect errors in the B+tree structure earlier. Since I've also fixed a big bug in r24410 that could have clobbered your disk before, I'm closing this bug. Without more information, I can't do anymore, anyways - and that particular thing cannot happen anymore that way.

Note: See TracTickets for help on using tickets.