Opened 13 years ago

Closed 13 years ago

#1239 closed bug (fixed)

Duplicated and corrupted directories

Reported by: jackburton Owned by: axeld
Priority: high Milestone: R1
Component: System/libroot.so Version: R1/pre-alpha1
Keywords: Cc: bonefish
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

Since a few revisions, I'm getting duplicated and truncated folder names. Screenshot attached.

Attachments (1)

screenshot.png (21.8 KB ) - added by jackburton 13 years ago.

Download all attachments as: .zip

Change History (13)

by jackburton, 13 years ago

Attachment: screenshot.png added

comment:1 by axeld, 13 years ago

Component: System/KernelBuild System
Owner: changed from axeld to bonefish

When build under Linux, I would guess? We recently switched to a new bfs_shell, so I would expect the problem to be there.

in reply to:  1 comment:2 by jackburton, 13 years ago

Replying to axeld:

When build under Linux, I would guess?

Yes, sorry, I should have specified.

comment:3 by korli, 13 years ago

Did you use the -j option for jam ?

in reply to:  3 comment:4 by jackburton, 13 years ago

Replying to korli:

Did you use the -j option for jam ?

No. I also tried to do a full rebuild (jam -qa haiku.image) but the problem persists.

comment:5 by bonefish, 13 years ago

Mmh, "since a few revisions" doesn't quite sound like since hrev20975 (almost 3 weeks ago). Or do you think, I could have been since then?

Since everything works fine here, it would be nice, if you could test a few things. One would be to create an empty image (just insert an "exit 0" in build/scripts/build_haiku_image before the image is mounted (second bfs_shell invocation)), run the bfs_shell interactively ("jam -q run ':<build>bfs_shell' :haiku.image") and try to create a few directories.

The other thing would be to add a bit of output in src/tools/fs_shell/fssh.cpp:command_mkdir() (print to stderr).

Since I'm clueless what code be the source of the problem, ATM, we'll have to see what those tests turn up and probably investigate a little further.

in reply to:  5 comment:6 by jackburton, 13 years ago

Replying to bonefish:

Mmh, "since a few revisions" doesn't quite sound like since hrev20975 (almost 3 weeks ago). Or do you think, I could have been since then?

I would think it started after that, (actually I thought it could've been hrev21200, but if fixing a memory leak breaks BFS this much...) but I can't be sure because I didn't test any image carefully enough since hrev20975 or also before that.

Since everything works fine here, it would be nice, if you could test a few things. One would be to create an empty image (just insert an "exit 0" in build/scripts/build_haiku_image before the image is mounted (second bfs_shell invocation)), run the bfs_shell interactively ("jam -q run ':<build>bfs_shell' :haiku.image") and try to create a few directories.

The other thing would be to add a bit of output in src/tools/fs_shell/fssh.cpp:command_mkdir() (print to stderr).

Since I'm clueless what code be the source of the problem, ATM, we'll have to see what those tests turn up and probably investigate a little further.

I'll try to do those tests later or tomorrow. BTW I've just downlaoded the image built from hrev21224 at HaikuHost ( http://haikuhost.com/housestrain/ ) and it suffers from the same problem.

comment:7 by bonefish, 13 years ago

My source tree was few days old (hrev21173). After updating it I can reproduce the problem, too. Will investigate further ...

comment:8 by bonefish, 13 years ago

Cc: axeld added

I verified, that the produced image is indeed not OK. Mounting it under BeOS works, but listing e.g. home directory results in "No such file or directory" messages for the entries. Mounting and listing with the bfs_shell under Linux works fine, though; no duplicate/broken directories to be seen. As checked via debug output, when populating the image, bfs_create_dir() is invoked only once per directory, with the correct name.

Using binary search, I tracked the first revision for which the image is broken down to hrev21194 (Stefano, can you verify this please). I fail to see, how the change would be related, though. It affects only Haiku kernel and libroot. The bfs_shell should not even be rebuilt. I wouldn't rule out an indirect effect due to a size change of files copied to the image, which might trigger a BFS bug, but at least the sizes of kernel and libroot.so remain the same (didn't check stuff linked against them).

Ideas what could be the reason or how to track the problem down are most welcome.

in reply to:  8 comment:9 by jackburton, 13 years ago

Replying to bonefish:

Using binary search, I tracked the first revision for which the image is broken down to hrev21194 (Stefano, can you verify this please).

Correct. hrev21194 is indeed the first revision which shows this bug.

comment:10 by axeld, 13 years ago

Owner: changed from bonefish to axeld

I think there is a pretty simple explanation for this: I must have broken find_directory() with those changes, causing it to create the wrong entries. I'll look into it.

comment:11 by axeld, 13 years ago

Cc: bonefish added; axeld removed
Status: newassigned

comment:12 by axeld, 13 years ago

Component: Build SystemSystem/libroot.so
Resolution: fixed
Status: assignedclosed

Fixed in hrev21239. Sorry, bonefish for letting you find my bugs again - at least next time I'll investigate first before you'll get my victim again :-)

Note: See TracTickets for help on using tickets.