Dr. Volker Zell wrote:
> This is the relevant code block in alternatives.c where the above file
> gets read by the function readConfig (buf should hold the contents of the above file
> after the do loop):
>
>
> curBufSz = READCONFIG_BUF_INITIALSZ;
> totalBytesRead = 0;
> numBytesRead = 0;
> buf = NULL;
> do
> {
> if (curBufSz < READCONFIG_BUF_BEHAVIOR_THRESH)
> curBufSz *= 2;
> else
> curBufSz += READCONFIG_BUF_BEHAVIOR_THRESH;
>
> buf = realloc(buf, curBufSz + 1);
>
> bufp = buf + totalBytesRead;
try putting
*bufp = '\0';
right here.
> numBytesRead = read(fd, bufp, curBufSz - totalBytesRead);
>
> /* don't add '-1' ! */
> if (numBytesRead > 0)
> totalBytesRead += numBytesRead;
> }
> while (numBytesRead > 0);
>
> (gdb) p bufp
> $38 = 0x664a08 "1\n20\nµ"
Whoa. That is odd. I wonder if it's an uninitialized memory thing --
realloc does not zero out the "new" storage; it only copies over the old
storage up to the old storage's length.
> (gdb) p buf
> $39 = 0x6649e8 "auto\n/usr/bin/gs\n\n/usr/bin/gs-x11\n20\nµ"
>
> and then later on in parseLine after a while:
>
> bufp=µ
>
> and boom...
Yep, that would do it.
> It looks like something went wrong in line 219
>
> numBytesRead = read(fd, bufp, curBufSz - totalBytesRead);
>
> Also numBytesRead=5, bufp="1\n20\nµ" instead of "1\n20\n"
>
>
> I have no idea where the µ comes from.
>
> Running alternative on one of your packages is fine:
Memory issues are always tricky. If the fix above corrects the error,
I've got to wonder how we've been so lucky on all the other packages
that use the alternatives system...
--
Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/