$Log$ substitution in binary files.

[Derek Robert Price]

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

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.

Cheers,

Derek

- --
                *8^)

Email: derek@ximbiot.com

Get CVS support at <http://ximbiot.com>!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBQNJbLD1OTBfyMaQRAogFAJ9wYFBwLKRpswA3KaT4PC93irgUHgCg85ng
o1WgPp0Ro/y5HOWk1e1i4qU=
=7STr
-----END PGP SIGNATURE-----