From:	"John M. Aldrich" <fighteer AT cs DOT com>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: I'm going slightly mad!!
Date:	Tue, 24 Feb 1998 23:06:16 -0500
Organization:	Two pounds of chaos and a pinch of salt.
Lines:	46
Message-ID:	<34F398B8.3F09@cs.com>
References:	<199802250048 DOT QAA28497 AT adit DOT ap DOT net> <34F393E9 DOT AEA57781 AT mail DOT coos DOT or DOT us>
NNTP-Posting-Host:	ppp207.cs.com
Mime-Version:	1.0
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Jason Dagit wrote:
> 
> I have the same experiences.  I haven't had gcc crash.  Well, I did *once*.  But
> I don't think it was related to this problem, I think it was a bug.  Now that I
> think about it, I should try to get it happen again and see if it is a bug.  Back
> to the subject of the post.  The problem doesn't just happen on my computer
> either.  I use Allegro and I have made a few demo programs.  I compiled them on
> my home machine after getting them to work.  Took them to school and tried to
> show them to a teacher, and (some of them) wouldn't run, it was humiliating.
> Then, I came back home tried to run it, and it crashed, I tried again and it
> worked.  Strange if you ask me.  I think it has to do with the Win95 DPMI server.

It's possible, because Win95 doesn't check for such anomalies as NULL
pointer dereferences, which can really hose your computer.

Other causes for programs crashing on some computers and not others
include:

 - Interrupt handlers or the memory they touch not being locked, thus
causing crashes when the program pages on low-memory computers.
 - Rogue or uninitialized pointers, or improper calls to memory
allocation routines.  In particular, uninitialized pointers or
uninitialized memory can show totally different symptoms depending on
the machine you run on and/or the time of day and phase of moon.
 - Bad memory management (fragmentation, etc.).
 - Insufficient allocation of DPMI resources on the host machine.
 - Use of hardware-dependent code in the program, which run afoul of
faulty or unsupported host hardware.  Or possibly some piece of code
that is only used on certain hardware is itself buggy (this happened to
me once).

Some of these problems can be caught by making the compiler act as
pessimistic as possible when giving warnings/errors.  For maximum
pessimism, use the '-Wall', '-O', '-W', and '-Werror' command line
switches; these force an absolutely clean compilation.  '-ansi' and
'-pedantic' can also be useful troubleshooters.

hth

-- 
---------------------------------------------------------------------
|      John M. Aldrich       | "If 'everybody knows' such-and-such, |
|       aka Fighteer I       | then it ain't so, by at least ten    |
|   mailto:fighteer AT cs DOT com   | thousand to one."                    |
| http://www.cs.com/fighteer |                 - Lazarus Long       |
---------------------------------------------------------------------

- Raw text -