[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KCrash API
From:       David Faure <david () mandrakesoft ! com>
Date:       2000-04-13 9:10:21
[Download RAW message or body]

Did you note my comment in the last commit, about the strange
docu in kcrash.h ?
Basically, to define you own handler, passing the name of a
static void blah (int)
function works fine, no need for the very strange syntax the
header docu suggests.

But then I realised that calling signal(SIGSEGV,myfunctionname)
did exactly the same job, so I'm not sure KCrash is really useful
in that context (this is about kioslaves, which are daemons, i.e.
no data to save and no dialog box to pop up)... ;-)

Anyway, my point is : that docu doesn't look right to me.

On Thu, Apr 13, 2000 at 11:36:26AM +0200, Hummel, Timo wrote:
> Hi kde-core-devel and kde-devel,
> 
> today I'll write a few lines about the API for KCrash so developers can
> already start implementing the crash functions. Thanks to Tom Braun, David
> Faure and Waldo Bastian (and others) who improved the code which I wrote so
> poorly :)
> 
> Introduction
> -----------------
> 
> KCrash are a few functions to set crash handlers for different signals.
> Technically, they are only wrappers for signal(3), but also include support
> for an emergency save function. The signal handlers are automatically
> replaced whenever you refer to KApplication, except if you specified
> "--nocrashhandler" as argument for the application or set an environment
> variable called KDE_DEBUG to something. By default, the new KDE crash
> handler will be called (with support for the emergency save function,
> recursion handling and displaying Dr. Konqi), unless the user configured
> something else in the control panel (a module and implementation follows
> later). If the user configured KCrash not to handle signals, the emergency
> save function won't be called at all.
> 
> The KCrash handler sits in KApplication and collects important data which
> will be displayed in Dr. Konqi later. Currently, only the application name,
> application path and the signal number will be displayed, plus an additional
> i18n'ed description in Dr. Konqi.
> 
> Functions
> -----------------
> 
> There are a few functions you need to use if you want to:
> - Define your own crash handler
> - Define your own emergency save function
> - Extent the KCrash interface with new informations displayed
> 
> 
> KCrash::setEmergencySaveFunction (void (*saveFunction) (int));
> 
> Pass your user-defined function to this one, and it will be called whenever
> a crash occurs. If you don't want an emergency save function, just pass NULL
> to it. You can also change this during run-time, if you want to have several
> emergency save functions in different parts of your application. If your
> emergency save function crashes, the KDE default crash handler recognizes
> this and does a normal shutdown (no infinite loop).
> 
> KCrash::setCrashHandler (void (*crashHandler) (int));
> 
> Pass your user-defined crash-handler function to this one, and it will be
> used as crash handler. Make sure that your function does not crash itself,
> or this might crash your whole machine (always implement a recursion
> counter). You can additionally specify NULL to use the system's crash
> handler or KCrash::defaultCrashHandler to use the KDE crash handler
> (default).
> 
> If you want everything being handled automatically, you don't need to do
> anything, since everything is made in the KApplication class. The default
> behaviour is: Catch SIGSEGV, launch Dr. Konqi and display the informations.
> If there are other suitable signals which should be handled, please tell me.
> 
> Yours
> Timo

-- 
David FAURE
david@mandrakesoft.com, faure@kde.org
http://home.clara.net/faure/
KDE, Making The Future of Computing Available Today

[prev in list] [next in list] [prev in thread] [next in thread]