Ticket #1239 (closed bug: fixed)

Opened 3 years ago

Last modified 3 years ago

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: Platform: All
Blocking:

Description

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

Attachments

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

Change History

Changed 3 years ago by jackburton

follow-up: ↓ 2   Changed 3 years ago by axeld

  • owner changed from axeld to bonefish
  • component changed from System/Kernel to Build System

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   Changed 3 years ago by jackburton

Replying to axeld:

When build under Linux, I would guess?

Yes, sorry, I should have specified.

follow-up: ↓ 4   Changed 3 years ago by korli

Did you use the -j option for jam ?

in reply to: ↑ 3   Changed 3 years ago by jackburton

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.

follow-up: ↓ 6   Changed 3 years ago by bonefish

Mmh, "since a few revisions" doesn't quite sound like since r20975 (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   Changed 3 years ago by jackburton

Replying to bonefish:

Mmh, "since a few revisions" doesn't quite sound like since r20975 (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 r21200, 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 r20975 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 r21224 at HaikuHost (  http://haikuhost.com/housestrain/ ) and it suffers from the same problem.

  Changed 3 years ago by bonefish

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

follow-up: ↓ 9   Changed 3 years ago by bonefish

  • 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 r21194 (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   Changed 3 years ago by jackburton

Replying to bonefish:

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

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

  Changed 3 years ago by axeld

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

  Changed 3 years ago by axeld

  • cc bonefish added; axeld removed
  • status changed from new to assigned

  Changed 3 years ago by axeld

  • status changed from assigned to closed
  • resolution set to fixed
  • component changed from Build System to System/libroot.so

Fixed in r21239. 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.