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