[haiku-bugs] Re: [Haiku] #5374: Contents of files ending up in other files
- From: "mmlr" <trac@xxxxxxxxxxxx>
- Date: Fri, 05 Feb 2010 19:54:44 -0000
#5374: Contents of files ending up in other files
---------------------------+------------------------------------------------
Reporter: mmlr | Owner: bonefish
Type: bug | Status: new
Priority: critical | Milestone: R1
Component: System/Kernel | Version: R1/Development
Keywords: | Blockedby:
Platform: All | Blocking:
---------------------------+------------------------------------------------
Description changed by mmlr:
Old description:
> With a r32401 kernel (updated from a previous r35294 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 r35393 with it's write-back related changes.
New description:
With a r35401 kernel (updated from a previous r35294 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 r35393 with it's write-back related changes.
--
--
Ticket URL: <http://dev.haiku-os.org/ticket/5374#comment:1>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
