On Wed, 2009-11-11 at 11:05 +0100, Jiri Moskovcak wrote:
On 11/05/2009 05:49 PM, Mark Wielaard wrote:
> The code is already setup to save if in a different place if necessary
> (in fact if the current directory isn't writable for the user it will
> try saving in /tmp). If /var/log/java is made writable for all users
> that could be a place to dump the log also.
> The code can also be modified to actually call abrt (or an helper
> executable/script) if necessary either with the path of the log file or
> even with an open file descriptor to the log.
We use a helper to handle the python logs, so I think we could use the
same helper for saving the java logs.
Do you have a pointer to the code for this helper?
>> The other thing I have in mind is how to catch an unhandled
>> java programs, because in this case the VM exits "normally" and abrt
>> can't detect it. We managed to catch these exception in python by
>> overriding the default exception handler by script that is automatically
>> loaded everytime when python VM is started. If there would be some way
>> to this for java we could wire this to ABRT.
> In principal we could install some uncaught exception handler, but
> uncaught exceptions might not be fatal (although they are admittedly
> sloppy). The program may even happily run even if one thread has an
> uncaught exception (as long as there are other non-daemon threads
ABRT doesn't care if it is or isn't fatal, this is up to your exception
handler - you can just log the exception using the abrt helper (because
even if the exception is not fatal, it's usually a bug..) and contiune
running the program.
This part is trickier than the above. In case of a JVM crash there is a
clear point where we catch that crash and produce the necessary logs for
a bug report. In case of an application specific uncaught exception
there is an uncaught exception handler mechanism, but the application
could already be using it (either for a specific Thread, the ThreadGroup
or system wide). This might require some surgery to get right (and
unobtrusive for the application running on the JVM).
> How would you determine which package the exception belongs to?
For a VM
> crash it is almost always the java VM package that should get the bug
> report (since the VM just shouldn't crash ever).
If I'm right the Java VM is compiled, so it creates a coredump and would
be handled by a different hook then scripts, but that applies only if
you don't catch the sigsegv, sigabrt (whichI think you do, to create the
logs..) and let it die.
Yes, the VM catches fatal signals and creates an hs_err log file based
on the information it can still retrieve at that point before dying.
I think, as Java VM is a non-trivial programme,
we should write a special handler for it, or we can try to improve the
general hook for compiled programs to be able to handle some additional
data as the log file if that would be enough.
> But for uncaught
> exceptions reporting it against the java VM package is definitely the
> wrong thing to do. How do you solve that in the python case?
The python exception hook is run in the context of the running script,
so it knows the script name and the path to the script and then we can
simply run $ rpm -qf /path/to/script to determine the package, the code
to do this is:
executable = os.path.abspath(sys.argv)
Aha. I think we could determine the main class that is being run and the
classpath with .jar/.zip files that this class comes from. With that we
could probably achieve similar heuristics about the package that
provided the classes.