Date: Sun, 17 Dec 2000 15:37:29 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: djgpp AT delorie DOT com Subject: Re: gcc.exe barfs on simple hello.c file. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Sun, 17 Dec 2000, Andris Pavenis wrote: > I once saw bad behaviour of one 486 box when tried to run DJGPP compiled > programs (not a compiler itself though). Real mode DOS applications worked > mostly Ok. When I tried to build DJGPP app with memory allocation > debugger included (I used Fortify-2.2) I saw random changes of single bits > in deallocated memory: I think rather evidently pointing to hardware > problems. Yes, I've seen such problems as well. I once had a year-long debugging session, because Emacs would crash on me once every few weeks (the low frequency was the reason for the long debugging: I needed to wait until the problem happens again, after each change I made to track down the problem). Eventually, I found out that in each instance of the crash, a single bit was flipped in one of the important variables, such as nil, which are central to the Emacs Lisp's internal operation, because each data structure is typically terminated by nil. Such single-bit changes are very hard to find. In my case, the break-through happened once I compared corrupted data structures with the same data structures in a fresh Emacs session, and saw that where the uncorrupted structure had a nil, the corrupted one had a value which differed by a single bit.