Message-ID: In-Reply-To: References: Conversation with last message Priority: Normal X-MSMail-Priority: Normal X-Priority: 3 To: djgpp-workers AT delorie DOT com Cc: erik2 DOT berglund AT telia DOT com MIME-Version: 1.0 From: "Erik Berglund" Subject: Re: Re: gcc-crash - and a possible solution Date: Thu, 24 Jun 99 21:15:13 +0100 (DJG) Content-Type: text/plain; charset="ISO-8859-1"; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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