Re: $Log$ substitution in binary files.

[Mark D. Baushke]

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

Derek Robert Price <derek@ximbiot.com> writes:

> I recently got a report that the checkout of a binary file that a user
> forgot to tag as binary caused CVS to exit with an error because it
> couldn't allocate over 2GB of data.
> 
> Based on the gdb trace, it looks like the code that blew up was
> attempting to substitute in the log message after a $Log$ keyword.  I
> saw "after a" here rather than "in place of" because the $Log$ keyword
> is treated differently than other keywords.
> 
> For those of you familiar with $Log$ substitution, skip to the end -
> I'm including a refresher for others.
> 
> CVS makes certain assumptions about the environment of the $Log$
> keyword.  Namely, that anything previous to it on the _line_ should be
> repeated before each log line inserted by CVS.  This is so that a
> construct like:
> 
> /*
>  * $Log$
>  */
> 
> Can be replaced by:
> 
> /*
>  * $Log$
>  *
>  * author ... date ...
>  * <LOG MESSAGE #1 line 1>
>  * <LOG MESSAGE #1 line 2>
>  * ...
>  */
> 
> and this subsequently replaced by:
> 
> /*
>  * $Log$
>  *
>  * author ... date ...
>  * <LOG MESSAGE #2 line 1>
>  * <LOG MESSAGE #2 line 2>
>  * ...
>  *
>  * author ... date ...
>  * <LOG MESSAGE #1 line 1>
>  * <LOG MESSAGE #1 line 2>
>  * ...
>  */
> 
> CVS determines the comment leader dynamically based on the file
> content so that it would work just as well for a perl or shell script
> with:
> 
> # $Log$
> 
> 
> 
> Those familiar with $Log$ can start reading again:
> 
> You get the idea.  Without a copy of the file, I can't say for sure,
> but I'm guessing that what happened in the binary file is that CVS
> found a $Log$ keyword, then backed up until the first \n or the
> beginning of the file.  This could include an awful lot of data in a
> large executable, especially if the $Log$ keyword was found near the
> end of the file.  Then CVS attempted to allocate space to put the
> "comment leader" it found in this manner, possibly almost an entire
> copy of the file for each "line" of the log message (including the
> metadata lines, author, date, etc...).  This was more memory than it
> could allocate.
> 
> Anyhow, there isn't anything specifically wrong with what CVS is doing
> here - it's supposed to make assumptions about files in which the user
> has "requested" keyword substitution (or failed to mark binary).
> Regardless, a 20 character limit on the size of the $Log$ comment
> leader seems reasonable, so I'm going to hardcode a 256 character
> limit on the comment leader into CVS if there are no objections.

Interesting....

However, I'd suggest that in the case where the search back to find a \n
for <number-of-characters> does not find it, that cvs falls back to the
old-style RCS 'comment' character as the prefix to use by default.

In theory, a prefix of 1024 characters could be set if the user did a

  cvs admin -c '<how-ever-many-characters-is-desired>' filename

to explicitly set a prefix that exceeds your <number-of-characters>
heuristic limit...

        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFBQRTD3x41pRYZE/gRAg4QAJ4o/knY4clfBaKYBuYaY0NUNq72egCcDkOY
3EilrOxynPfWxOvqXjmmKaw=
=UXL2
-----END PGP SIGNATURE-----