Re: [Crash-catcher] java reports by crash catcher

[Michal Nowak]

----- "Mark Wielaard" <mjw(a)redhat.com&gt; wrote:

>  Hi,
>  
>  It would be nice if crash-catcher could be thought about the
>  hs_pid*.log
>  files that a crashed java process creates. That file contains much
>  more
>  information that is relevant to the crash than the gdb backtrace that
>  is
>  currently collected. If it can see if there is a hs_pid###.log file
>  (where ### is the process id of the java process that crashed) and
>  attached that to the bug report it files that would be appreciated.
>   
I am afraid Java exceptions are not supported at the moment (just the
python ones) and thus ABRT is not being run in such cases.

Do you have some example crash, where ABRT stepped in?

Since Java apps exception handling is completely missing, perhaps
some of you guys can help?

>  Thanks,
>  
>  Mark 
Michal

>  
>  _______________________________________________
>  Crash-catcher mailing list
>  Crash-catcher(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/crash-catcher

[Crash-catcher] java reports by crash catcher

[Mark Wielaard]

Hi Michal,

On Wed, 2009-11-04 at 06:11 -0500, Michal Nowak wrote:
>  I am afraid Java exceptions are not supported at the moment (just
> the
>  python ones) and thus ABRT is not being run in such cases.
>  
>  Do you have some example crash, where ABRT stepped in? 
For example: https://bugzilla.redhat.com/show_bug.cgi?id=532913
Which isn't as useful as it could be. If the VM detects a crash it will
generate a hs_pid###.log file, which we would normally request a user
attaches to their bug report. For example here:
https://bugzilla.redhat.com/attachment.cgi?id=360967
As you can see it has a lot more useful information about the crash than
just the C backtrace of the VM.

Thanks,

Mark

[Crash-catcher] java reports by crash catcher

[Jiri Moskovcak]

On 11/04/2009 12:18 PM, Mark Wielaard wrote:
>  Hi Michal,
>
>  On Wed, 2009-11-04 at 06:11 -0500, Michal Nowak wrote:
> > I am afraid Java exceptions are not supported at the moment (just the
> > python ones) and thus ABRT is not being run in such cases.
> >
> > Do you have some example crash, where ABRT stepped in?
>
>  For example: https://bugzilla.redhat.com/show_bug.cgi?id=532913
>  Which isn't as useful as it could be. If the VM detects a crash it will
>  generate a hs_pid###.log file, which we would normally request a user
>  attaches to their bug report. For example here:
>  https://bugzilla.redhat.com/attachment.cgi?id=360967
>  As you can see it has a lot more useful information about the crash than
>  just the C backtrace of the VM.
>
>  Thanks,
>
>  Mark
>  
Hi, it shouldn't be that hard to inlude these log into report. Can you 
tell me where the log files are saved?

Jirka

>  _______________________________________________
>  Crash-catcher mailing list
>  Crash-catcher(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/crash-catcher

[Crash-catcher] java reports by crash catcher

[Mark Wielaard]

On Wed, 2009-11-04 at 13:23 +0100, Jiri Moskovcak wrote:
>  Hi, it shouldn't be that hard to inlude these log into report.
> Can you 
>  tell me where the log files are saved? 
They are saved in the current working directory of the java process. So
normally $HOME, but if the user did cd /bla/dir/foo and started the java
process there, it would go into /bla/dir/foo.

[Crash-catcher] java reports by crash catcher

[Mark Wielaard]

On Wed, 2009-11-04 at 13:46 +0100, Mark Wielaard wrote:
>  On Wed, 2009-11-04 at 13:23 +0100, Jiri Moskovcak wrote:
>  > Hi, it shouldn't be that hard to inlude these log into report. Can you 
>  > tell me where the log files are saved?
>  
>  They are saved in the current working directory of the java process. So
>  normally $HOME, but if the user did cd /bla/dir/foo and started the java
>  process there, it would go into /bla/dir/foo. 
Forgot to tell you have to easily reproduce this. Start some java based
program (eclipse or netbeans for example if you have it installed on
your fedora machine). Notice the pid and do kill -SIGSEGV pid. If you
started from some terminal it will print some info about what it is
doing:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000003c38e07b0b, pid=7244, tid=140043694540528
#
# JRE version: 6.0-b16
# Java VM: OpenJDK 64-Bit Server VM (14.0-b16 mixed mode linux-amd64 )
# Distribution: Custom build (Thu Sep 10 12:14:10 EDT 2009)
# Problematic frame:
# C  [libpthread.so.0+0x7b0b]  pthread_join+0x10b
#
# An error report file with more information is saved as:
# /tmp/temp/hs_err_pid7244.log
#
# If you would like to submit a bug report, please include
# instructions how to reproduce the bug and visit:
#   http://icedtea.classpath.org/bugzilla
#

Here you see I did a cd /tmp/temp first, before starting the program, so
that is why it saves the hs_err_pid file there.

Cheers,

Mark

[Crash-catcher] java reports by crash catcher

[Jiri Moskovcak]

On 11/04/2009 01:49 PM, Mark Wielaard wrote:
>  On Wed, 2009-11-04 at 13:46 +0100, Mark Wielaard wrote:
> > On Wed, 2009-11-04 at 13:23 +0100, Jiri Moskovcak wrote:
> >> Hi, it shouldn't be that hard to inlude these log into report. Can you
> >> tell me where the log files are saved?
> >
> > They are saved in the current working directory of the java process. So
> > normally $HOME, but if the user did cd /bla/dir/foo and started the java
> > process there, it would go into /bla/dir/foo.
>
>  Forgot to tell you have to easily reproduce this. Start some java based
>  program (eclipse or netbeans for example if you have it installed on
>  your fedora machine). Notice the pid and do kill -SIGSEGV pid. If you
>  started from some terminal it will print some info about what it is
>  doing:
>
>  #
>  # A fatal error has been detected by the Java Runtime Environment:
>  #
>  #  SIGSEGV (0xb) at pc=0x0000003c38e07b0b, pid=7244, tid=140043694540528
>  #
>  # JRE version: 6.0-b16
>  # Java VM: OpenJDK 64-Bit Server VM (14.0-b16 mixed mode linux-amd64 )
>  # Distribution: Custom build (Thu Sep 10 12:14:10 EDT 2009)
>  # Problematic frame:
>  # C  [libpthread.so.0+0x7b0b]  pthread_join+0x10b
>  #
>  # An error report file with more information is saved as:
>  # /tmp/temp/hs_err_pid7244.log
>  #
>  # If you would like to submit a bug report, please include
>  # instructions how to reproduce the bug and visit:
>  #   http://icedtea.classpath.org/bugzilla
>  #
>
>  Here you see I did a cd /tmp/temp first, before starting the program, so
>  that is why it saves the hs_err_pid file there.
>
>  Cheers,
>
>  Mark 
The problem is, that abrtd (the abrt daemon) can't read anything from 
~HOME directory as it's considered a security risk. So we need to save 
this logs somewhere else maybe /var/log/java in could work, but I might 
be missing some bad side effects of this. We could read this file in 
time when user tries to report it from abrt-gui but it would be better 
to collect this log in time of crash, as it could be deleted before user 
decides to report it. (and auto-reporting wouldn't work either as it is 
run as root).

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.

Thanks,
Jirka


>  _______________________________________________
>  Crash-catcher mailing list
>  Crash-catcher(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/crash-catcher

[Crash-catcher] java reports by crash catcher

[Mark Wielaard]

On Wed, 2009-11-04 at 14:01 +0100, Jiri Moskovcak wrote:
>  The problem is, that abrtd (the abrt daemon) can't read anything
> from 
>  ~HOME directory as it's considered a security risk. So we need to save 
>  this logs somewhere else maybe /var/log/java in could work, but I might 
>  be missing some bad side effects of this. We could read this file in 
>  time when user tries to report it from abrt-gui but it would be better 
>  to collect this log in time of crash, as it could be deleted before user 
>  decides to report it. (and auto-reporting wouldn't work either as it is 
>  run as root). 
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.

>  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).

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). 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?

Cheers,

Mark

[Crash-catcher] java reports by crash catcher

[Jiri Moskovcak]

On 11/05/2009 05:49 PM, Mark Wielaard wrote:
>  On Wed, 2009-11-04 at 14:01 +0100, Jiri Moskovcak wrote:
> > The problem is, that abrtd (the abrt daemon) can't read anything from
> > ~HOME directory as it's considered a security risk. So we need to save
> > this logs somewhere else maybe /var/log/java in could work, but I might
> > be missing some bad side effects of this. We could read this file in
> > time when user tries to report it from abrt-gui but it would be better
> > to collect this log in time of crash, as it could be deleted before user
> > decides to report it. (and auto-reporting wouldn't work either as it is
> > run as root).
>
>  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.

> > 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.

>  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. 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])

Jirka

>  Cheers,
>
>  Mark
>
>  _______________________________________________
>  Crash-catcher mailing list
>  Crash-catcher(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/crash-catcher

[Crash-catcher] java reports by crash catcher

[Mark Wielaard]

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
> 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).

>  > 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[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

[Crash-catcher] java reports by crash catcher

[Jiri Moskovcak]

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
>
>  _______________________________________________
>  Crash-catcher mailing list
>  Crash-catcher(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/crash-catcher

[Crash-catcher] java reports by crash catcher

[Jiri Moskovcak]

Hi,
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.

Have a nice day,
Jirka

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
> >
> > _______________________________________________
> > Crash-catcher mailing list
> > Crash-catcher(a)lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/crash-catcher
>
>
>
>  _______________________________________________
>  Crash-catcher mailing list
>  Crash-catcher(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/crash-catcher

[Crash-catcher] java reports by crash catcher

[Mark Wielaard]

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.

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.

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).

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
>  >>
>  >> _______________________________________________
>  >> Crash-catcher mailing list
>  >> Crash-catcher(a)lists.fedorahosted.org
>  >> https://fedorahosted.org/mailman/listinfo/crash-catcher
>  >
>  >
>  >
>  > _______________________________________________
>  > Crash-catcher mailing list
>  > Crash-catcher(a)lists.fedorahosted.org
>  > https://fedorahosted.org/mailman/listinfo/crash-catcher
>

[Crash-catcher] java reports by crash catcher

[Jiri Moskovcak]

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?

>  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
> >>>
> >>> _______________________________________________
> >>> Crash-catcher mailing list
> >>> Crash-catcher(a)lists.fedorahosted.org
> >>> https://fedorahosted.org/mailman/listinfo/crash-catcher
> >>
> >>
> >>
> >> _______________________________________________
> >> Crash-catcher mailing list
> >> Crash-catcher(a)lists.fedorahosted.org
> >> https://fedorahosted.org/mailman/listinfo/crash-catcher
> >
>
>

[Crash-catcher] java reports by crash catcher

[Mark Wielaard]

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

[Crash-catcher] java reports by crash catcher

[Jiri Moskovcak]

On 10/11/2010 04:03 PM, Mark Wielaard wrote:
>  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?
>  
ABRT knows the cwd and the pid of the crashing process so it should be 
able to read hss_err_<pid>.log file I will play with it.

> >> 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
>

[Crash-catcher] java reports by crash catcher

[Jiri Moskovcak]

On 10/12/2010 02:30 PM, Jiri Moskovcak wrote:
>  On 10/11/2010 04:03 PM, Mark Wielaard wrote:
> > 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?
> >
>
>  ABRT knows the cwd and the pid of the crashing process so it should be
>  able to read hss_err_<pid>.log file I will play with it.
>  
The problem with <CWD> is that it could be different every time and even 
if it's writable for JVM it could be not-readable for ABRT (like $HOME) 
and makes SELinux to complain. So what about /var/log/openjdk/ or (not 
sure how nice it is..) jvm could open stderr write the log there and not 
close it, the abrt handler could open /proc/<pid>/2 and read the log 
from there (not sure how secure this is and how selinux will like it...)

> >>> 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
> >
>
>  _______________________________________________
>  Crash-catcher mailing list
>  Crash-catcher(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/crash-catcher