ABRT frustrating for users and developers

[Michael Schwendt]

On Sun, 17 Jan 2010 13:09:56 +0100, Nicolas wrote:

> > A downside is that ABRT is triggered for all sorts of weird
> > memory/heap
> > corruption that isn't reproducible. Stability problems with RAM chips
> > are widespread.
> > 
> > A bugzilla stock response that points at "memtester" and "memtest86+"
> > will likely be needed more often.
> 
> That seems totally unecessary and counter-productive to me. You can
> distinguish between local memory problems and actual hard-to-trigger
> bugs without bothering users by checking if the trace is reported by
> abrt for other systems.

How?

I'm always willing to learn.

Here are two examples:

* http://bugzilla.redhat.com/538379 : no idea how to reproduce it -
upstream cannot reproduce it and cannot tell whether it may be fixed in a
newer release - Ubuntu is hit hard by it currently - I've contributed
proof-reading various parts of the code and external libs and have found
issues, but nothing specific to this problem.

* http://bugzilla.redhat.com/543610 : no steps on how to reproduce it -
reporter cannot reproduce it either - no context is given for the
application that crashes - it could be reassigned to gtk2, but is there
enough evidence that gtk2 is the culprit? I don't think so. This time
gtk2 clist is hit, next time it's glibc's memory management again.

Do we have guidelines about when to reassign a ticket to another
component?

> I know it's very human to shoot the messenger but packagers &
> developpers should resist the urge to make tester life miserable to
> punish them from reporting inconvenient problems.

The request to give the RAM some testing is not impolite.