'recover' crashes in hash::Put()

[dsuden]

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 ​https://pastebin.com/9g7mcUtf Compiled with g++ with the latest sources downloaded from cgit.haiku-os.org (we also tried on 32bit haiku, but 'recover' runs out of memory slightly before reaching 100%, hence the 64bit attempt)

[korli]

Please attach the pastebin to the ticket.

[dsuden]

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.

[jua]

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).

[dsuden]

Debug version of 64 bit recover

[dsuden]

We also tried the same test with the guarded heap:

LD_PRELOAD=libroot_debug.so 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>

[ttcoder]

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.

[korli]

Please see ​https://git.haiku-os.org/haiku/commit/src/bin/bfs_tools/recover.cpp?id=4498948fcf2c37bd2752df34513f59b96bad8658 and check after hrev51861 whether it is fixed.

[waddlesplash]

No reply, so assuming it is.

[ttcoder]

Yup

[nielx]

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