Mail Archives: djgpp-workers/1999/06/24/15:17:37
Eli Zaretskii wrote:
> On Wed, 23 Jun 1999, Charles Sandmann wrote:
>
> > We have a new malloc since the previous version - I would double check
> > it for signed/unsigned address clean and/or replace it with the old
version.
>
> Thanks, I will try to look into this.
>
> At least judging by the traceback that was produced by the latest port
> of EGCS, it was built with the new malloc, but the problem is still
> there. It is possible, however unlikely, that both the new and the
> old malloc share some common bug wrt signed and unsigned, but it seems
> more likely that the problem, if it's in the library, is in some other
> place.
>
> Another reason might be specific to GCC. Since the crashes happen
> inside obstack, it might be a good idea to see whether obstack code
> assumes that the addresses it gets from malloc are contiguous and/or
> consistently increasing. If it does, then using the Unixy sbrk is
> *the* solution.
>
Yes, I think it could be specific to GCC, and maybe to win3.11 as well.
I did some experimenting and printed out the addresses coming from
malloc-calls in CC1.EXE, there were several hundreds of them, and
some of them were below 2 Gbyte, and some were above 2 Gbyte,
it all came out in a random fashion.
I also noticed that win3.11 has some kind of "memory" regarding
what programs have previously been run. I think win3.11 does not
free all memory when a Windows program exits.
As a sidepoint, that's also consistent with the behaviour I've
observed in Internet Explorer 3.0.1153:
After surfing around the world an hour or so, with images enabled,
the Explorer won't work properly, some fonts become bigger and
other strange things happen, and finally I have to restart Windows.
Then, everything works ok again. I think it's a special "feature"
in win3.11 and/or Explorer.
So I think that after I've run my special 3-program sequence,
to trigger the gcc-crash, the win3.11 internal memory allocation
is in a certain state, and would return to ___sbrk and malloc some
addresses, that are above 2 Gbyte, and that may perhaps
trigger the error. These addresses are located below the
start of CC1.EXE code section, maybe win3.11 happened
to found a free hole just there.
Whenever I try Unixy sbrk, it will consistently give me addresses
below 2 Gbyte, and CC1.EXE will consistently work,
not a single error since 2 Jun 1999, when I first started
to examine the Unixy sbrk hypothesis. It may or may not
be the final solution, but it probably has something to do
with the error, anyway.
Do you know if win95 can give addresses above 2 Gbyte?
Maybe Microsoft has improved the memory allocation, so it
simply doesn't happen any more (or happens very occasionally).
Also, I think win3.1 (the old version before win3.11) had
a yet worse memory allocation mechanism, so it wouldn't
even go and find empty holes, so maybe win3.1 never
returned addresses above 2 Gbyte either, and that's
why you never saw the error on win3.1. But that's
just my guess.
I was thinking about upgrading to win98, but then I
thought it might be a good idea to find this error first,
now that it is so easy to reproduce on win3.11.
Erik
- Raw text -