Mail Archives: djgpp-workers/1999/07/03/11:05:19
Charles Sandmann wrote:
> Eli Zaretskii wrote:
>
> > You should be able to achieve the same effect with
> > `_CRT0_FLAG_FILL_SBRK_MEMORY', it also zeroes out all allocated
> > memory.
>
> If setting this flag causes it to work, its a smoking gun that
> there is a program bug.
I've tried this flag on CC1.EXE, but unfortunately, the error
was still there. Instead I think there's some error in the handling of
pointers >2Gb, and the error only happens in some very rare cases.
Probably it shows up on win3.11, because it seems that win3.11
doesn't free all memory automatically when a program exits,
only some of the allocated blocks are freed.
Then there may be lots of small free holes, which may be allocated
by malloc but only when the requested size is small enough to fit.
This may be the reason to why malloc returns blocks in reversed
order sometimes: The first sbrk call (1 Mbyte CC1 code and data
segment) is located at a rather high physical address, whereas
subsequent small malloc's can well be located at lower physical
addresses provided that the memory is fragmented enough.
On the other hand, win95 probably handles memory in another way
and frees all memory blocks automatically on program exit, so we
don't have the same situation there.
I think the reason that unix-sbrk acts as a work-around is
because it resizes a single memory block which in effect makes
malloc consistently return addresses <2Gb.
Any other ideas welcome,
Erik
- Raw text -