Looks like the java-devel list disgarded any email from non-subscribers
(so that included my initial email and your reply). Hope that is fixed
now. I left all text in the email, even though my reply consists of only
on tiny paragraph so others can catch up on the discussion.
On Mon, 2010-10-11 at 15:32 +0200, Jiri Moskovcak wrote:
On 10/11/2010 03:19 PM, Mark Wielaard wrote:
> Hi Jiri,
>
> On Wed, 2010-10-06 at 10:11 +0200, Jiri Moskovcak wrote:
>> what about resurrecting this feature for F15? We made some changes to
>> abrt so it uses socket instead of the helper app, so we can send you the
>> info on how to use it if you'd be interested in implementing it to javavm.
>
> I currently don't have the time to work on this, but do think they are
> good ideas that would improve abrt a lot for java/jvm based packages.
>
> I added Fedora Java Developers list to the CC in the hope someone would
> be interested. So if someone is looking for a fun (python!) hack, this
> might be interesting.
>
Actually it would be probably more C fun.
> One idea is that abrt/crash-catcher creates a lot of bugzilla reports
> against the jvm package. Those do include a native backtrace, but don't
> include the (often far more useful) hs_err_pid.log file. It would be
> nice if abrt would find it and offer to automagically attach it to the
> bug report.
Attaching the file is not a problem, but does it live in some
predictable location?
It lives in the current working directory of the JVM. In theory one
could hack the hotspot sources to place it somewhere else. But what
would be a good place?
> The other idea discussed was when a java program exits through
an
> uncaught exception in the main thread. In that case you might want to
> catch that and create a bug report against the package that contains the
> main class file (instead of against the jvm package).
>
This one is actually what I'd like to be done in F15.
> The first idea is probably the least work and has the most benefit in
> the short term (at least for the java-1.6.0-openjdk bug maintainers).
>
>> On 11/16/2009 09:43 AM, Jiri Moskovcak wrote:
>>> On 11/13/2009 11:00 AM, Mark Wielaard wrote:
>>>> 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?
>>>
>>>
http://git.fedorahosted.org/git/abrt.git?p=abrt.git;a=blob;f=src/Hooks/ab...
>>>
>>>
>>>>
>>>>>>> The other thing I have in mind is how to catch an unhandled
>>>>>>> exception in
>>>>>>> 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
>>>>>> running).
>>>>>>
>>>>> 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).
>>>>
>>>
>>> This is really up to you as I don't know much about about insides of
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.
>>>>
>>>
>>> Ok, so we need to find the way how to pass this logs to abrt hook.
>>>
>>>>> 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[0])
>>>>
>>>> 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.
>>>>
>>>> Thanks,
>>>>
>>>> Mark