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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
