----- "Mark Wielaard" <mjw(a)redhat.com> wrote:
> It would be nice if crash-catcher could be thought about the
> files that a crashed java process creates. That file contains much
> information that is relevant to the crash than the gdb backtrace that
> 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?
> Crash-catcher mailing list
Our default config has "OpenGPGCheck = no" so it's possible to report
bugs in non-Fedora packages.
1. we should enable it in stable release (F12)
2. we should find another way how to determine if package comes from
koji and belongs to Fedora, because users can easily disable gpg checking
Both names and paths are different.
I propose using abrt-xxx scheme for every binary's name
(btw, maybe for dumpoops too?).
That will fix one discrepancy - in the name.
Does it make sense to move abrt-pyhook-helper to /usr/libexec?
Currently, we are using the fact that it is in /usr/bin
by not specifying the /path/to/it when we call it:
command = ["abrt-pyhook-helper"]
command.append("--pid=%s" % pid)
command.append("--executable=%s" % executable)
command.append("--uuid=%s" % tb_uuid)
I usually like this, but here it maybe isn't the best idea.
What if /usr/bin is NOT in the $PATH at this point, in this python
If we decide to have a full path there, then also moving to /usr/libexec
looks like a no-brainer.
What say you?
I was thinking about catching crashes in abrtd (I know is pretty stable,
but still...). We decided not to catch it, because when the daemon is
not running there is no quota for dumpdir size. So here is my proposal:
We can hardwire the /usr/sbin/abrtd to be handled specially by the hook
so it will be saved into the same dir (like /var/cache/abrt/abrt-dump/)
and overwriting the previous coredump. this way we'll avoid filling up
the HDD. But there could still be a problem when if abrtd crashes in a
loop then creating coredump might be I/O time-consuming, this can be
solved by checking the timestamp of the last crash and setting some
Ideas are more than welcome,
Immediate planned work:
* Deployment doc: prepare unsuspecting vict^W^W user/admin
who installs and uses abrt for the first time what to expect.
It needs to answer user-centric information about "How Do I Do X?
How Do I Do Y?". Example doc for yum:
Douglas Silas <dhensley(a)redhat.com> may help with review
* Design doc needs updating/consolidating:
doc/DESIGN and https://fedorahosted.org/abrt/wiki/AbrtArchitecture
* Identify list of known critical bugs/badly needed features for RHEL6,
email it to Radek.
* ccpp hook should fall back to analyzing coredump
if /proc/PID/exe is not readable.
* ongoing work in determining why X crashes on jmoskovc machine
produce truncated coredumps.
* Make "Enabled = yes" to work in per-plugin .conf files.
* Discuss auto-dlopening of plugins.
* New directive in CCpp.conf:
DebugInfoDir = /path/to/debuginfos:/path/to/debuginfos2:...
this in effect adds DebuginfoFS functionality to abrt
* Put text files _also_ in BZ comment field if they are small
(currently they are always attached).
* Add version info to "abrt X.Y.Z detected a crash" BZ comment.
* Add [Cancel] button to "Do you really want to send <something>?"
Please reply to this email when you committed to git
a change which fulfills one of the points above.
Denys, thank you very much for the Catcut plugin. I finally got a
chance to look at it, and do some simple testing. It looks pretty good.
I've filled out the add_attachment code in a patch below. I would
appreciated it if you would review it, and check it in if it's acceptable.
In writing this code I have come to believe that all of the plugins
would benefit from having common bits of code factored out into a plugin
support library, rather than cut and pasted from one plugin to another.
I'm curious what other ABRT developers think of this.
Also in looking at several plugins, I've noticed that different plugins
have different policies for reporting errors, warnings, informational,
and debugging messages. Sometimes exceptions are used, sometimes calls
to 'update_client' and sometimes calls to 'log'. Is there a
pattern/policy that I just haven't figured out yet, or is this still in