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

List:       kde-devel
Subject:    Re: 3.0 RELEASE: Heading RC1
From:       Bryce Nesbitt <bryce () obviously ! com>
Date:       2002-01-18 18:18:31
[Download RAW message or body]

Waldo Bastian wrote:
> 
> On Thursday 17 January 2002 04:03 pm, Bryce Nesbitt wrote:
> > --------------------------------------------------------------------------
> > API Question:
> > Do people feel there is enough, consistent, information contained in KDE 3
> > binaries to facilitate the future expansion of bug reporting systems?
> >
> > Specific food for thought:
> >       * Can KCrash always extract the KAboutData information?  If KCrash
> >         has to scan the binary for it, would a magic cookie help?
> 
> KCrash does not scan the binary.
> 
> But KCrash in KDE3 is very unreliable due to the use of threads. When a crash
> happens within malloc the whole process will lock up in the crash handler.
> 
> Without threads we would just segfault again in the crash handler and exit.

What's the solution?  Or at least the hook for a future solution?

Is there enough header information in KAboutData that a future KCrash could
scan the binary, and formulate an automated bug report?  It would be easy
to surround the static data with magic cookies, for later extraction.

Could kicker notice who died and write a log file?

I ask now, because if anything needs to be done to the binary format, it
may already be too late to start...



Jono Bacon wrote:
> 
> On Friday 18 January 2002 12:03 am, Bryce Nesbitt wrote:
> > Here I'm thinking about building something better than FullCircle Talkback
> > or Microsoft's IE error reporting.  An institution or individual could
> > elect to provide automated feedback about their KDE to kde.org.
> 
> This is a great idea, and I think the API should definitly provide further
> expansion where neccecery. Also, anything that helps curve the bugs.kde.org
> dumping ground would be cool.

The goal would be that the low quality "it just crashed on me and I don't
know why" reports would not make it to bugs.kde.org.  They would just be
statstics.  The top 10% of methods with segfaults, for example, would
be looked at before each new release.  The worst 1% of the KDE applications
in terms of user crashes would be considered for suspension or removal.

			-Bryce
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]