Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#5374 closed bug (fixed)

Contents of files ending up in other files

Reported by: mmlr Owned by: bonefish
Priority: critical Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: Cc: Jens.Arm@…
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by mmlr)

With a hrev35401 kernel (updated from a previous hrev35294 one) I have buildtools failing during a second Haiku build run. Inspecting the files that were built using a -aqj8 build just minutes ago they ended up having contents of other files in them. As an example I'll attached the linkcatkeys binary that is a normal executable up to 0x00010000 and then contains what appears to be data from the svn update run up to a certain point and then continues to be a normal executable. My steps were:

1) Reboot

2) Trying to build Haiku to another partition which failed in various tools (likely due to this problem)

3) Build Haiku to another partition using "-ajq8" to ensure all tools to be rebuilt which worked fine

4) Noticing that I forgot to update to the latest sources, so doing an svn update

5) Trying to re-build to said partition with "-jq8" which failed stumbling over collectcatkeys (which contained some text instead of the expected executable data), after deleting collectcatkeys so it would be rebuilt it failed to run linkcatkeys

6) Inspecting linkcatkeys to find it contained stuff it shouldn't

7) Getting a little worried and opening this bug

It seems to me that since the "-a" build ran through just fine that the files were valid when they were created and cached in memory and then got corrupted when written back. After rebooting the files are broken in the same way, so they definitely ended up broken on-disk. Therefore I'd suspect hrev35393 with it's write-back related changes.

Attachments (1)

linkcatkeys (116.2 KB ) - added by mmlr 10 years ago.

Download all attachments as: .zip

Change History (11)

by mmlr, 10 years ago

Attachment: linkcatkeys added

comment:1 by mmlr, 10 years ago

Description: modified (diff)

comment:2 by mmlr, 10 years ago

After looking a bit more closely the wrong content in linkcatkeys seems to be part of a preprocessed source file judging for the "# <line> <header>" lines present. The partition this happens on is a separate non-indexed BFS partition where I keep all the source, so it is unlikely that a preprocessed file would just happen to be there (as all of that usually goes to the /tmp dirs on /boot). So to me it looks like that the content of a different file is actually written back to this one and it not being just a previously freed BFS block which isn't fully overwritten. The drive was in use previously, but the content I see there (localekit, icu) has not been integrated back then I think, so I'm pretty sure it's no leftover from that either.

comment:3 by phoudoin, 10 years ago

Sounds like either block cache error or VM error.

I think I'm having since few weeks/revision similar errors under network or io activity, which lead eventually to corrupt git cached objects, screwing the local clone copy.

comment:4 by bonefish, 10 years ago

Status: newin-progress

comment:5 by bonefish, 10 years ago

Resolution: fixed
Status: in-progressclosed

I don't have a good test case to verify that, but hrev35477 should fix the issue. I'd recommend to wait with updating, until I've also addressed #5404 and #5382.

comment:6 by bonefish, 10 years ago

Resolution: fixed
Status: closedreopened

Just ran into a file corruption with hrev35488 (with hrev35473 and hrev35464 reverted) during a -j2 Haiku image build with available RAM reduced to 1 GB: The first page of the gensyscalls executable had incorrect contents. So apparently hrev35477 didn't fix the issue (completely). It was such a nice explanation, though. ;-)

comment:7 by bonefish, 10 years ago

Status: reopenedin-progress

comment:8 by jahaiku, 10 years ago

Cc: Jens.Arm@… added

comment:9 by bonefish, 10 years ago

Resolution: fixed
Status: in-progressclosed

Should be fixed for good in hrev35500.

comment:10 by phoudoin, 10 years ago

Well, I would trust a round revision number ;-)

Note: See TracTickets for help on using tickets.