On 01/18/2010 09:34 AM, Alexander Larsson wrote:
On Mon, 2010-01-18 at 09:31 +0100, Alexander Larsson wrote:
> On Sun, 2010-01-17 at 13:02 +0000, Camilo Mesias wrote:
>
>> Having said that the things that can be done with a mere backtrace
> are
>> limited. I would almost always need to look at the corefile too, and
>> would be frustrated if it wasn't available. Perhaps the workflow
> that
>> starts with ABRT providing a backtrace needs to be significantly
>> different to the workflow for a manually submitted bug. More
> automated
>> perhaps?
>>
>> What if every component had a placeholder bug for undiagnosed ABRT
>> info. Keeping all of them together would help to gauge which are
>> significant and which are one-in-a-million cosmic rays flipping RAM
>> bits etc.
>
> I think it should work more like the mozilla crash handling system.
> They
> file automatic crash reports in a completely different database which
> is
> more optimized for e.g. data mining and is less work for the
> maintainer
> on a per-bug basis. So, instead of replying and keeping track of every
> user crash manually the maintainer gets list of "top crashers it
> latest
> version", "new crashes this week", etc.
In case you're interested this is how the mozilla database looks:
http://crash-stats.mozilla.com/
I agree. The current infrastructure doesn't go well with ABRT. To be
able to detect duplicates we need to compare the whole backtraces not
just hashes and that can't be done with bugzilla(the only way to do this
is to download all backtraces from bz and compare them on user computer,
which is really not acceptable). So having similar server as Mozilla
uses is our plan also. Then we can recreate (without sending a core
file) the trace on server without forcing users to install the debuginfo
and process the whole BT the way we want without consuming users CPU
time, etc..
Jirka