From: James Colannino <james@colannino.org>
To: Linux C Programming List <linux-c-programming@vger.kernel.org>
Subject: Re: glibc: realloc(): invalid next size
Date: Thu, 20 Jul 2006 23:10:40 -0700 [thread overview]
Message-ID: <44C06FE0.9000300@colannino.org> (raw)
In-Reply-To: <44C01B7E.4070308@colannino.org>
James Colannino wrote:
> Hey everyone. I'm having great difficulty debugging a function of mine
> that adds more memory as needed when reading variable length lines.
>
> When I run the code, it always fails after readline() calls addmemory()
> for the second time (no matter how I change linebuf->buflen, or don't
> change it...) If readline only has to call addmemory() once, no matter
> what the size of memory being passed is, it works.[...]
I found the bug (for what it's worth.) It was very subtle, but it
caused catastrophic results at runtime. Notice line 6 below (I numbered
them.) This is the while loop in readline(). It says that it should
start counting down again from linebuf->buflen elements after the
reallocation. The problem is, half of those spaces are already filled,
so when I start counting down again from such a high number, forgetting
that half is already filled, I think I must blow away bookeeping
information stored by the memory allocator, thus, while the first call
to realloc() is successful, the second one isn't.
I changed that line of code to:
6: buflen = linebuf->buflen - bufcount;
That way, it makes sure to take into account those spaces which have
already been used. This code when compiled runs perfectly. Sorry for
the noise to the list. I honestly have been banging my head over this
one and really couldn't find a good solution (I was starting to suspect
something was up with glibc, which probably wasn't very bright :-P),
otherwise I wouldn'tve asked the question.
>1: while ((c = getc(linebuf->fp)) != EOF) {
>2:
>3: if (buflen <= 2) { /* need more memory */
>4: bufcount = bufpos - start;
>5: start = addmemory(linebuf);
>6: buflen = linebuf->buflen;
>7: bufpos = start + bufcount;
>8: }
>9:
>10: *(bufpos++) = c;
>11: buflen -= 1;
>12:
>13: if (c == '\n') { /* we're done with one line */
>14: *bufpos = '\0';
>15: break;
>16: }
>17: }
James
--
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/
"Black holes are where God divided by zero." --Steven Wright
prev parent reply other threads:[~2006-07-21 6:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-21 0:10 glibc: realloc(): invalid next size James Colannino
2006-07-21 6:10 ` James Colannino [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44C06FE0.9000300@colannino.org \
--to=james@colannino.org \
--cc=linux-c-programming@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).