Opened 3 years ago

Closed 19 months ago

Last modified 4 months ago

#13931 closed bug (fixed)

'recover' crashes in hash::Put()

Reported by: dsuden Owned by: axeld
Priority: normal Milestone: R1/beta2
Component: Applications/Command Line Tools Version: R1/Development
Keywords: Cc: ttcoder
Blocked By: Blocking:
Platform: All


We tried the BFS tool "recover" twice, to recover/undelete a deleted file; crashed both times. Second time we used the guarded heap to get more info: the .report is over at Compiled with g++ with the latest sources downloaded from (we also tried on 32bit haiku, but 'recover' runs out of memory slightly before reaching 100%, hence the 64bit attempt)

Attachments (2)

9g7mcUtf.txt (150.7 KB ) - added by mmlr 3 years ago. (12.1 KB ) - added by dsuden 3 years ago.

Download all attachments as: .zip

Change History (13)

comment:1 by korli, 3 years ago

Please attach the pastebin to the ticket.

comment:2 by diver, 3 years ago

Owner: changed from nobody to axeld
Status: newassigned

by mmlr, 3 years ago

Attachment: 9g7mcUtf.txt added

comment:3 by dsuden, 3 years ago

Dane here...If someone can get this working, I can guarantee them $200 as a bounty. Please contact me if you need me to work with you on this, do testing, etc.

Thanks much.

comment:4 by jua, 3 years ago

A few things which might be helpful:

  • Build the recover tool in debug mode. To do so, edit the file (or create it, if it doesn't yet exist) build/jam/UserBuildConfig in the Haiku source tree. Add a line:

SetConfigVar DEBUG : HAIKU_TOP src bin bfs_tools : 1 : global ;

Then rebuild the recover tool with jam. Observe the path where it's built in now at the end of the jam process, it will not be the same as the release build you did before.

  • Then reproduce the crash with the debug version. Create a crash-report and attach it here. Note: the debug report will include memory dumps of the recover process, which might include snippets of data from your disk, so you need to decide if you want to attach it publicly here.
  • Ideally, create one crash report with and one report without using libroot_debug (i.e. guarded heap)
  • Please also attach here the "recover" binary you built (in a ZIP file). The information from the crash report is only useful in conjuction with the specific binary that crashed, and since you build it yourself, it's easier if you attach it than trying to reproduce it on a dev's machine (which needs same hrev, compiler package, source repo revision, etc).

comment:5 by dsuden, 3 years ago

Debug version of 64 bit recover

comment:6 by dsuden, 3 years ago

We also tried the same test with the guarded heap: MALLOC_DEBUG=ges50 recover

/dev/disk/ata/0/master/1 /Recover

but that one remained stuck: it went as far as 48%, then remained stuck for <1 hour xyz minutes> (after which we rebooted the computer) with the following display:

<.....48% ..etc>

comment:7 by ttcoder, 2 years ago

All is well that ends well:

Tweaked recover.cpp to have huge initial hashtables, thus working around the need to ever resize them as nodes are read. No more crash.

comment:9 by waddlesplash, 19 months ago

Resolution: fixed
Status: assignedclosed

No reply, so assuming it is.

comment:10 by ttcoder, 19 months ago

Cc: ttcoder added


comment:11 by nielx, 4 months ago

Milestone: UnscheduledR1/beta2

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone

Note: See TracTickets for help on using tickets.