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.