Message-ID: In-Reply-To: References: Conversation with last message Priority: Normal X-MSMail-Priority: Normal X-Priority: 3 To: "Eli Zaretskii" Cc: djgpp-workers AT delorie DOT com, sandmann AT clio DOT rice DOT edu MIME-Version: 1.0 From: "Erik Berglund" Subject: Re: Re: gcc-crash - and a possible solution Date: Tue, 29 Jun 99 01:14:10 +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 Sat, 26 Jun 1999 pavenis AT lanet DOT lv wrote: > > > cc1.exe, cc1plus.exe etc. are nothing else than large C > > programs that doesn't use any very special hacks > > This is probably true, but some surprises can still lurk in GCC's code. > For example, it uses obstack which could assume all kinds of assumptions > about memory addresses to manage memory efficiently. I have continued my search for the error details, and now it seems that CC1.EXE 2.7.2.1 for some odd reason sometimes jumps to slightly wrong addresses! According to the traceback anyway, we have: 1) CC1 calls _obstack_free() in the last call. That's wrong, it should not call _obstack_free() normally. Instead, it should call obstack_free() (without underscore, because __GNUC__ is defined). In _obstack_free(), the parameters are probably wrong, because it's the wrong routine, and CC1 crashes. 2) CC1 calls 0x1017 in the last call. This is outside the program. oballoc()+0x20 tries to call _obstack_newchunk() but for some odd reason it jumps to 0x1017 and crashes. 3) CC1 calls 0x8d3 in the last call. The same observation as in 2). 4) CC1 jumps into a local textstring (within obstack.c I think), and tries to execute the data. It doesn't succeed and crashes. I wonder how this can happen. Seems like the routines move around somewhat in memory! Could the win3.11 DPMI server rearrange data and code if there was a strange bug in win3.11? > > 2) binaries of gcc-2.95 19990615 You tested before where linked > > with unmodified DJGPP-2.02. Current binaries (same place) > > of gcc-2.95 19990623 are linked with 16 June CVS version of > > DJGPP. However I doubt if there will be so serious changes in > > related parts of libc.a > > Actually, there was one change that might be related: malloc mixed signed > and unsigned in several places. So I'd suggest to see if the latest > binaries still have this problem. Erik, could you please do that? Yes, I can do that in a day or so, and I will send a report then how it went. As an experiment, I rewrote malloc, free and realloc from scratch again, and used DPMI-calls 0x501, 0x502 and 0x503 in a straight-forward manner. In PMODE V1.2, everything worked well for small C-programs, and if I tried to compile a large C-program, 0x501 did not succeed. But that was expected, because PMODE V1.2 only supports 120 memory blocks or so. In win3.11, everything worked ok for small programs, but if I used my 3-program sequence and a C-program with lots of "static" variables in the beginning, CC1 crashed, in the same manner as usual. There were no error messages from DPMI-calls 0x501, 0x502, 0x503. Then, I removed DPMI-calls 0x502 and 0x503 (they are not really needed), and only kept 0x501. Interestingly, CC1 still crashed in win3.11 in the usual way. So, in my homemade CC1, I have removed malloc.c entirely, and sbrk is only used initially, by crt0.S. CC1 still crashes in odd places, and I only use DPMI-call 0x501 (one for each malloc call). However, obstack.c is still in use, maybe there is something wrong there. But only in win3.11? Only sometimes? Finally, I also removed DPMI-call 0x501. Instead, I allocate a big 16 Mbyte buffer the first time malloc is called, and then I use it for subsequent memory requests. DPMI memory-calls are thereby totally bypassed until CC1 exits. This approach works. I even had malloc to return new addresses in reversed order, to check the block-order-sensitivity of CC1. It still works. Then I would suspect the win3.11 DPMI server again. If DPMI-calls are not used, or if PMODE or CWSDPMI are used, CC1 2.7.2.1 runs perfectly. However I think I had problems with CC1 2.8.1 both in DOS box and in plain DOS mode (CWSDPMI r3), but I will check that again later. For your information, I found a crash report in the djgpp-list archive, from 14 April 1998, titled "gcc crash". The program version seems to be CC1.EXE 2.7.2.1 with DJGPP 2.01. Maybe it's the same error here, because the traceback looks rather familiar: error in flow.c, however the CS-, DS-limits etc. are different compared to my tracebacks. Thanks for any ideas, Erik