Message-ID: <000501c05f64$6852d080$3e14883e@gtdf>
From: "Greg Holdridge" <greg AT holdridge7 DOT freeserve DOT co DOT uk>
To: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Cc: <djgpp AT delorie DOT com>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1001206094236 DOT 10098D-100000 AT is>
Subject: Re: realloc causing fault
Date: Wed, 6 Dec 2000 09:10:27 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Reply-To: djgpp AT delorie DOT com


----- Original Message -----
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Greg Holdridge <greg AT holdridge7 DOT freeserve DOT co DOT uk>
Cc: <djgpp AT delorie DOT com>
Sent: Wednesday, December 06, 2000 7:44 AM
Subject: Re: realloc causing fault


>
> Not necessarily.  There are many subtle quirks in how memory is
> managed by Windows and DJGPP programs.

Ok yes you're absolutely right (see below)

> One string whose length is 1:
>
>    strtable[numstrings-1].len = str->len;
>    strtable[numstrings-1].buffer = malloc(str->len);
>
> and str->len is 1 in the program you posted.

Fair enough.  Just an example though - the real program will do strings..
however...

> Sorry, I don't follow your reasoning, probably because I don't know
> enough about the problem you are trying to solve.

Decompress a file done in bog-standard LZW compression - all ASCII
characters are roots.

> small chunk at a time.  This will cause a massive memory fragmentation
> in most malloc implementations (one sign of this fragmentation is that
> the address goes up all the time, that is, memory allocated for the

Ok silly me. I did some calculations. I allocate 16 bytes per stringentry
(including 8 byte overhead right?) and immediately afterwards I allocate a
buffer which i presume will use the memory at the end of the stringtable.
Therefore the stringtable cannot expand (because of the calimed memory at
its end) and so must move leaving a fragment which will never again hold the
table.  This means (a few calculations) that the effective space of the
stringtable is the sum of all tghe sizes it ever was.  For 7000 strings
then, the table takes the sum of an arithmetic series like:

             (7000/2) *  (16 + [7000*16])  =  392056000 bytes = 374 meg
(when all I need is 150 K)

This is nightmarish.

> Where did you get these references?  This looks like part of the DJGPP
> crash traceback, but you told above that it isn't printed?  If this
> _is_ a DJGPP traceback, please post the rest of it.

Sorry I CAN get the traceback under plain DOS but am unable to scoop it into
a suitable file for posting here however I think it doesnt matter since I
have seen the light. Thanks a lot,

Greg