On Thu, 2010-11-04 at 17:51 +0000, Dr Andrew John Hughes wrote:
On 07:41 Thu 04 Nov , Ralf Corsepius wrote:
snip...
As a maintainer, abrt to me primarily means "wading through wakes of hardly readable emails", mostly to scan them for useful information. I many cases I ended up with closing BZ, because these emails did not contain sufficient info.
That said, as a maintainer, abrt to me only has introduced a higher noise/signal ratio in bugreports as before.
This is the problem we have with java-1.6.0-openjdk, except it's magnified by the fact that the user could be running *ANYTHING* on the JVM. So if some native code in a Java application crashes the JVM, we get an abrt bug report for it.
The information provided is pretty much always useless for diagnosing the issue. The attached crash report is pretty incomprehensible for the JVM. Including the hs_err_<pid>.log generated by the JVM would at least be a start in making it easier to see what the failure was. But the main problem is that there is pretty much no way of reproducing most of these crashes and the user often has no clue what happened.
Could some of this by alleviated by teaching gdb a bit more about the insides of the JVM? (e.g. how to prettyprint JVM objects and stack frames?)
Doing the equivalent for CPython has been a huge improvement for the analogous situation: https://fedoraproject.org/wiki/Features/EasierPythonDebugging
Hope this is helpful Dave