Re: [Gnu-arch-users] PANIC: Top-of-file arch tag crosses 1k boundary

[John Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Actually, I believe the algorithm is look at the bottom 1k, then look at
the top 1k. At least when I was doing some profiling of what system
calls were being performed, that's what I saw. That was my understanding
as to why all of Tom's files end in the arch tag, instead of start with it.

If you look at src/libarch/inv-ids.c on line 1335 you find "search the
file itself (last, then first 1k").
If you look through the code, it seems to seek to the bottom
(SEEK_END-1026), and then read in 1025 characters.

And it seems to return from the function if it finds a valid tag, so it
shouldn't be looking at both the bottom and the top.

I'm really curious what is happening? I also am grep'ing for the strings
"Top-of-file", and I can't find anything

Do I have a different 1.2.1 than you do? I got mine from
release.gnuarch.org. And it has a valid signature from jblack.
John
=:->

Robert Anderson wrote:
| --- Original Message ---
| From: Aaron Bentley <address@hidden>
| To: Robert Anderson <address@hidden>
| CC: address@hidden
| Subject: Re: [Gnu-arch-users] PANIC: Top-of-file arch tag crosses
| 1k boundary
|
|
|>Robert Anderson wrote:
|>
|>>This is the error messages I get when I do 'tla changes' using
|>>the 1.2.1, which I just installed:
|>>
|>>PANIC: Top-of-file arch tag crosses 1k boundary
|>>
|>>Any ideas?  I don't have any arch-tags at the top of files.  I do
|>>have some in very small files, however, that I suppose could be
|>>interpreted as the "top" even though they are closer to the
|>>bottom than the top.
|>
|>Urk.
|>
|>Try to avoid one bug, you get another.  The rationale was that
|
| ids were
|
|>being truncated when their tags crossed the 1K boundary.  Rather
|
| than
|
|>fix it hastily, a PANIC was added, to prevent tla from silently
|
| doing
|
|>the wrong thing.
|
|
| Let me see if I understand.  There are two allowable places for
| tags in the file:  1k starting from the beginning of the file,
| and the last 1k of the file.
|
| The algorithm for finding a tag is: search the top, and if none
| is found, then search the bottom for the tag identifier.  If
| found in the "top", do this barrier-cross check on the tag to
| prevent unintended truncation.
|
| The failure mode here is that the tag was intended to be at the
| bottom of the file, but the file is short enough that the tag is
| in _both_ the "bottom" and "top" regions, although only partially
| contained in the "top" region.
|
| Shouldn't the algorithm look for the tag at the "bottom" location
| _first_?  And only if no tag is found, to search the top?
|
| Bob
|
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBLAH9JdeBCYSNAAMRAln+AJ9hlNkBsfMOO8PAXB6tOiMlwUmCOQCgwLUt
UIuK0J11upbPwRx0HTQBo3o=
=pIhW
-----END PGP SIGNATURE-----