Opened 17 months ago

Closed 4 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: Unscheduled
Component: Applications/Command Line Tools Version: R1/Development
Keywords: Cc: ttcoder
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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)

Attachments (2)

9g7mcUtf.txt (150.7 KB) - added by mmlr 17 months ago.
recover-791-debug-22-01-2018-11-55-44.report (12.1 KB) - added by dsuden 16 months ago.

Download all attachments as: .zip

Change History (12)

comment:1 Changed 17 months ago by korli

Please attach the pastebin to the ticket.

comment:2 Changed 17 months ago by diver

Owner: changed from nobody to axeld
Status: newassigned

Changed 17 months ago by mmlr

Attachment: 9g7mcUtf.txt added

comment:3 Changed 16 months ago by 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.

comment:4 Changed 16 months ago by 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).

comment:5 Changed 16 months ago by dsuden

Debug version of 64 bit recover

comment:6 Changed 16 months ago by 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>

comment:7 Changed 16 months ago by 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.

comment:9 Changed 4 months ago by waddlesplash

Resolution: fixed
Status: assignedclosed

No reply, so assuming it is.

comment:10 Changed 4 months ago by ttcoder

Cc: ttcoder added

Yup

Note: See TracTickets for help on using tickets.