Mail Archives: djgpp/2001/01/27/06:06:39
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.
- Raw text -