DrKonqi improvement idea

Thomas Zander zander at kde.org
Tue Mar 13 11:27:30 GMT 2012

Quoting Niko Sams <niko.sams at gmail.com>:

> On Mon, Mar 12, 2012 at 11:36, Thomas Zander <zander at kde.org> wrote:
>> I'd say this is a great idea, mostly because it means a lot more can be
>> automated on lots of ends.
>> Naturally, the actual automation means research and development, which means
>> manpower.   I didn't get from your email if you wanted to volunteer for some
>> of this work :)
>> Personally I'd go for a solution that also tries to register the last 20
>> keystrokes and 20 mouse clicks (qt global event listener) and if and when a
>> crash occurs that info can be send with the backtrace.  So even if there are
>> no debug packages installed we get some info to do data-mining on.
> That would provide useful information? I guess it depends on the
> application and bug.

In my experience its useful in many cases.  If your application is  
complicated then just having a backtrace, even with linenumbers, may  
not allow you to reproduce the crash. You need some extra info to know  
what the user did just before it crashed.
Asking the user is not the best solution; I've seen many backtraces  
with a comment from the user stating they were typing some text, while  
the backtrace showed they were printing. Its hard to be a debugger  
when your work just got lost...
A better solution would be that we know which buttons were clicked and  
that the user pressed the tab button or the ctrl-w buttons etc.
So, I'd say this can be very useful to get the whole picture of the  
moment the crash happened :)

And this also means that duplicates are good, the backtrace may be the  
same but we still add useful info to the issue.

>> Either case, I'd think you want something custom written. Its not too much
>> work to do the basics and maybe we can steal some code that compares
>> backtraces and steal some ideas or code for on-disk data-store of those
>> backtraces.
> +1
> The existing solutions are very complex and have lots of features. And
> they solve different
> use cases.

Hmm, its indeed not easy to find something fitting. Looking at the  
code of one of the links found in this thread, I notice its written in  
perl. While I understand the urge to do that, I'm not convinced that  
there is enough perl knowledge in KDE to make sysadmin happy if we  
just imported their systems. How hard can it be to parse a backtrace  
anyway? ;-)
Anyway, the actual core parsing and matching will probably be  
something that can be improved over time. Possibly with the help of  
other open source code.

Thomas Zander

More information about the kde-core-devel mailing list