Re: Some example code for a new crash handler



On Sat, 2002-01-12 at 02:00, Havoc Pennington wrote:
> 
> 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 tested that, but I found at that that doesn't happen.
When strlen(NULL) is called, it causes sigsegv, and then signal handler
is called.
When the signal handler returns, the program causes a sigsegv again, and
the handler is called yet again.
This goes on infinitely, until the program exits.
Thus strlen(NULL) will never be finished.
What I do is call gtk_main() in the signal handler, so it doesn't exits.
The GUI remains useable, and strlen(NULL) never returns.


> 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.
> 

It only shows one dialog per app.


> 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.
>  

That's why it's only intended to save the files before the program
exits, not to keep the program running forever.
Just save a few files won't take too long.


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

I think autosave AND keeping the program alive for a while after a crash
is even better.





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]