Date:	Sun, 17 Dec 2000 15:37:29 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	djgpp AT delorie DOT com
Subject:	Re: gcc.exe barfs on simple hello.c file.
In-Reply-To:	<Pine.A41.4.05.10012171212420.100456-100000@ieva06.lanet.lv>
Message-ID:	<Pine.SUN.3.91.1001217153021.6273A-100000@is>
MIME-Version:	1.0
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

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.

- Raw text -