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

List:       kde-devel
Subject:    Re: Thoughts from a former KDE, currently Mozilla developer
From:       Benoit Jacob <jacob.benoit.1 () gmail ! com>
Date:       2010-12-08 14:39:42
Message-ID: AANLkTimY4-ZAr8db_bcn5vZTgM7gNAuhRhbKmpT-NYd7 () mail ! gmail ! com
[Download RAW message or body]

2010/12/7 Andreas Pakulat <apaku@gmx.de>:
> On 07.12.10 14:28:57, Benoit Jacob wrote:
>> If I want to get a list of all KDE crashes that happened in libGL.so*,
>> how do I go about that?
>
> Thats more a problem of the tool we're using to track bugs, there's no
> way to tell bugzilla that something is a backtrace and what format it is
> in so that one can do more than a plain-text search on it.

Right, so here we find a concrete thing to fix: crash reports should
not land into bugzilla, nor should they land in any issue tracker,
rather they should land into a specialized database with a specialized
web interface.

> Also, with
> enough debug symbols you won't be able to search for libGL anyway as
> the backtrace has references to source files only.

How do you think that debuggers know the file? I think they just use
the modules map for the process, e.g. on linux it's /proc/$PID/maps,
that allows to find the object filename from the address.

Try this:
cat /proc/`pidof kwin`/maps


>
>> Regarding backtraces, as I said in my next email, it's not realistic
>> to expect the user to do anything more than click OK, when an app
>> crashed on him.
>
> I'm sorry, but I as a developer don't want to work with such users
> anyway. If a user isn't able or willing to provide information what he
> did for the crash to occur or tell me wether its reproduceable then I
> don't want to spend time on helping him. On the other hand, if the user
> is able/willing to do the above, he surely is able/willing to open his
> package manager and select a package or two (where the name is suggested
> by dr. konqi already) and then hit the reload button in dr. konqi.

Even if the x % of users who do this give you enough crash reports to
handle, you still lose the other aspect of crash reports: statistics.
It's just very useful to know the top 100 crash locations in an app,
and how crashiness changes over time.

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