Re: Some example code for a new crash handler

[Havoc Pennington <hp redhat com>]

Hongl Lai <hongli telekabel nl> writes: 
> And most of the crashes I encounter are caused by passing invalid memory
> addresses to function (i.e. strlen (NULL) or gtk_widget_show (100) and
> such) or free already free'ed memory.

So if you ignore segv on strlen(NULL), the result of the strlen could
be any random number. Say you're in the process of saving at that
point. The wrong strlen value could result in saving the wrong text
into a file, corrupting your document silently.

> I played with several ways to cause segfaults and I have yet to discover
> a way to *seriously* corrupt the program's memory so that the program
> can't even save anymore.

That's because the results of ignoring segv are basically random and
unpredictable. The chance of getting a serious problem after doing a
few tests is small. The chance of getting a serious problem if lots of
users are all doing this is perhaps larger.

> Most GNOME programs are desktop programs, not something extremely
> serious, so if the program becomes buggy after a crash then let it crash
> again (and exit).

I don't think showing a whole series of crash dialogs looks very
professional. If you have a "continue" button it should work, rather
than cause more crashes.

Also, continuing program execution will hose the stack more and more
badly, and ruin the backtrace in the bug report we currently get from
bug-buddy.
 
> BTW, if there's really no way to really fix the programs memory, then
> how do tools such as Norton CrashGuard work?

I have no idea. Not very well, I expect. But that isn't on UNIX,
anyhow.

> And how do program wirtten in Delphi manage to protect their own memory?
> (Delphi programs always show an error dialog when you try to overwrite
> memory/devide by zero/free nonexisting memory/etc. but the program never
> crash)

Delphi programs are not written in C. C doesn't have mechanisms for
this.

An autosave feature works great, and any reasonable app is going to
have one.

Havoc