From: rpolzer AT web DOT de (Rudolf Polzer)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Windows ME and DJGPP
References: <20010120205730 DOT 25849 DOT 00000491 AT ng-fd1 DOT aol DOT com> <3a6b7917 DOT 10793503 AT news DOT sci DOT fi> <3A6CB71F DOT 8B4E86C9 AT phekda DOT freeserve DOT co DOT uk> <94k3dc$lf9$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE> <slrn96u191 DOT 2cl DOT rpolzer AT rebounce DOT rpolzer-lx> <94pm3k$1qf$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE> <slrn970p9v DOT 28f DOT rpolzer AT rebounce DOT rpolzer-lx> <94rrk4$sro$1 AT antares DOT lu DOT erisoft DOT se> <slrn973r3m DOT 1vo DOT rpolzer AT rebounce DOT rpolzer-lx> <9003-Sat27Jan2001104054+0200-eliz AT is DOT elta DOT co DOT il>
X-newsgroup: comp.os.msdos.djgpp
X-realname: Eli Zaretskii
X-Mailer: GehtDichNenScheissdreckAn 1.0
Message-ID: <slrn9758nt.kg.rpolzer@rebounce.rpolzer-lx>
User-Agent: slrn/0.9.6.2 (Linux)
Date: Sat, 27 Jan 2001 11:29:17 +0100
Lines: 66
NNTP-Posting-Host: 213.7.28.115
X-Trace: 980591596 news.freenet.de 13141 213.7.28.115
X-Complaints-To: abuse AT freenet DOT de
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> schrieb Folgendes:
> > From: rpolzer AT web DOT de (Rudolf Polzer)
> > Newsgroups: comp.os.msdos.djgpp
> > Date: Fri, 26 Jan 2001 22:30:30 +0100
> > 
> > Martin Stromberg <eplmst AT lu DOT erisoft DOT se> schrieb folgenden Unsinn:
> > > Rudolf Polzer (rpolzer AT web DOT de) wrote:
> > > : The only memory allocation problems that really can occur in C++ are NULL
> > > : pointers (caught by the processor => SIGSEGV) and memory leaks (then you
> > > 
> > > That (getting SIGSEGV) won't work on WINDOZE if I'm not mistaken. Why
> > > don't you try it and see for yourself?...
> > 
> > My selfwritten REBOUNCE level editor always crashes on exit (after
> > saving) with a SIGSEGV and I do not know (probably I am freeing a bitmap
> > twice) why, but RHIDE always crashes after that so I cannot debug it. But
> > from this I know that SIGSEGV can also be caught on Windoze.
> 
> There are several different exceptions that DJGPP maps into SIGSEGV.
> Martin was talking about the one which happens because of NULL pointer
> dereference.  This triggers a Page Fault exception under CWSDPMI, but
> doesn't trigger any exception at all on Windows.  The reason is that
> the DJGPP startup code unmaps the null page (the first 4KB of the
> address space) from the program's address space, but Windows doesn't
> support the DPMI function used to do that.
> 
> Next time you get a SIGSEGV, read carefully the second line in the
> crash message.  That line tells what kind of exception crashed your
> program; on Windows you will usually see "General Protection Fault",
> not a "Page Fault".
> 
> The DJGPP FAQ list has more about this in section 12.2.
> 
> Btw, you should probably debug that SIGSEGV in your editor.  Perhaps
> section 12.2 in the FAQ can give you some ideas.

I tried, and it occurs at different positions in DOS and Linux. 
The DOS version crashes in allegro_exit (). No way to debug it, but I
am using the current Allegro WIP and it is not really serious. I just
found out that the Linux problem is in an automatic object, which I
enclosed in a block and now the error does not occur any more... in Linux. 
In DOS it still occurs. (It was me allocationg an automatic object which
contains a bitmap and destroys it in the destructor at the end of main
() ... and after allegro_exit ()! But allegro_exit () crashes in DOS).

But I just also tested a simple test program:

void main()
{
 char *p = 0;
 *p = 'X';
}

which compiles (with a warning about main being void) and crashes with a
SIGSEGV at the correct address. I see a GPF, but this is still enough
information because of the correct line numbers.
And I do not think clean code can contain a line which can produce many
errors that result in SIGSEGV but gives no hint about it.
Of course calling internal new or delete operators can produce such an
error, but I only know one way of creating a SIGSEGV with those
both: deleteing an object twice. And this can easily be handled by always
setting pointers to 0 after deleting.

-- 
Nuper erat medicus, nunc est vispillo, Diaulus:
Quod vispillo facit, fecerat et medicus.