From: "John M. Aldrich" 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk 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 | ---------------------------------------------------------------------