linux-c-programming.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

      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).