cmpilato@tigris.org writes:
> Author: cmpilato
> Date: Thu, 11 Jul 2002 01:35:28 -0500
> New Revision: 2465
>
> Modified:
> trunk/subversion/libsvn_subr/utf.c
> Log:
> * subversion/libsvn_subr/utf.c
> (convert_to_stringbuf): This function used to make looping calls to
> apr_xlate_conf_buffer, each time doubling an output buffer's size
> and retrying the whole conversion until success. Now, each loop
> only tries to convert the portion of the job not already finished by
> previous loops.
Just a heads-up for folks wondering what necessitated this change.
This function was SEGFAULTing on my box, where iconv() seems to only
handle 8160 bytes of output at a time.
Whenever Subversion tried to convert a buffer larger than that,
apr_xlate_conf_buffer (using iconv() under the hood) would convert
8160 bytes of it. convert_to_stringbuf would notice that the job
didn't complete, assume that the reason was because the output buffer
was too small, double the size of the output buffer, and try again.
Of course, doubling the size of the output buffer has no effect on the
fact that iconv() simply won't convert more than 8160 bytes. So we'd
end up looping, and doubling the output buffer size, until we simply
ate all the available memory on the machine, which is something that,
as it turns out, doesn't make for good software behavior. :-)
I found the bug while running `svn log -v' on a local copy of the
Subversion repository (up to revision 2320). At revision 2024 (you
all know the one...the stringbuf => const char * commit), the log
message was definitely larger than 8160 bytes, and that triggered the
bug. Now, `svn log -v' works on all 2320 revisions.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 11 08:54:26 2002