Date: Thu, 17 Aug 1995 01:52:47 -0400 From: Alan Bawden <Alan@Epilogue.Com> To: FreeBSD-gnats-submit@freebsd.org Subject: kern/695: cat B > C ; cmp B C can fail! Message-ID: <199508170552.BAA03086@beandorf.epilogue.com> Resent-Message-ID: <199508170600.XAA21510@freefall.FreeBSD.org>
next in thread | raw e-mail | index | archive | help
>Number: 695 >Category: kern >Synopsis: cat B > C ; cmp B C can fail! >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Aug 16 23:00:00 PDT 1995 >Last-Modified: >Originator: Alan Bawden >Organization: ITS Preservation Society >Release: FreeBSD 2.0-RELEASE i386 >Environment: FreeBSD 2.0 >Description: Here's a little dialog I just had a few minutes ago (with commentary): beandorf:temp> cmp -l A B 2108 367 377 2124 367 377 beandorf:temp> So A and B differ -- so what? Ah but look: beandorf:temp> cat A | cmp -l - B beandorf:temp> How could this be? Well it probably has something to do with the fact that when `cmp' is reading from a pipe it uses ordinary I/O operations (on -both- inputs), while if both inputs are disk files it uses `mmap' instead. Now check out how easily I can make more of these suckers: beandorf:temp> cat A > C beandorf:temp> cmp -l A C 2108 367 377 2124 367 377 beandorf:temp> cat B > D beandorf:temp> cmp -l B D beandorf:temp> cat B > E beandorf:temp> cmp -l B E 2108 377 367 2124 377 367 beandorf:temp> So, I can make this happen starting with -either- of the original files `A' or `B', but it doesn't happen every time because `D' matches `B' (when `mmap'ed anyway) but `E' doesn't. This dialog doesn't show it, but the `cmp' results are consistent if `cmp' is called again. That is, once `cmp' (using `mmap') tells you that X and Y differ, it always tells you that they differ. The dialog also doesn't show you that in this particular case, the errors are always the same two locations (2108 and 2124) and the same values (377 and 367). And sometimes I can cause a file to be created that only has one of the two locations wrong. I first noticed this problem because `touch' seems to have a tendency to create these monsters. But that isn't the only way, because I created `B' above using `cp'. This is all very strange, and it is shafting me totally. These files are actually `.o' files, and it has reached the point where whenever I get a Segmentation Violation I immediately delete all my recently created `.o' files, recompile them, relink, and the error is gone. >How-To-Repeat: All I can suggest is that the -contents- of that file may be implicated somehow. I have deleted all copies of that object file from my disk, along with a number of other problem-free object files, and then recreated them all, and after fooling around with `touch' and `cp' for a bit, only one file got into this broken state: the -same- file and at the -same- two locations! >Fix: Beats me. But I'd really appreciate it if someone would give me a clue what's going on here. It's pretty hard for me to imagine how a hardware bug could cause this, especially since the machine gets moderately heavy use and everything else seems to work perfectly! >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508170552.BAA03086>