[Crash-catcher] ABRT backtrace rating function
by Daniel Novotny
hello ABRT team,
the backtrace rating function is finally done. now it returns number of stars for the GUI to show,
ranging from 0 to 4.
the function is commited in the git. see lib/Plugins/CCpp.cpp
currently no GUI hooks, just the analyzer which outputs the number.
If you want to test it quickly, there's a standalone testing program at
http://people.fedoraproject.org/~dnovotny/f/ratebacktrace.cc
only the functions rate_line() and rate_backtrace() from this code were copied to the git,
the rest is boilerplate for this specific program
just give it a text file with backtrace in a parameter and it will output the number of stars
regards,
Daniel Novotny
14 years, 6 months
[Crash-catcher] another case when abrt fails to install debuginfo
by Jiri Moskovcak
Hi,
yesterday I was testing the latest release and I noticed that yum fails
to install debuginfo when previous yum transaction was cancelled.
packagekit just fails to install packages complaining that there are
some unfinished transactions and we get bt full of '?'. We really should
pass these errors to user and make him resolve it. Or if we don't have
debuginfo then we shouldn't even try to get bt? What do you think?
Jirka
14 years, 6 months
[Crash-catcher] abrt-debuginfo-install doc
by Denys Vlasenko
I am going to commit it to git as an inline comment,
refer to it later there:
src/Daemon/abrt-debuginfo-install
=================================
#!/bin/sh
# Called by abrtd before producing a backtrace.
# The task of this script is to install debuginfos.
#
# Just using [pk-]debuginfo-install does not work well.
# - they can't install more than one version of debuginfo
# for a package
# - their output is unsuitable for scripting
# - debuginfo-install aborts if yum lock is busy
# - pk-debuginfo-install was observed to hang
#
# Usage: abrt-debuginfo-install CORE TEMPDIR [CACHEDIR]
# If CACHEDIR is specified, debuginfos should be installed there.
# If not, debuginfos should be installed into TEMPDIR.
#
# Currently, we are called with CACHEDIR set to "/", but in the future
# it may be omitted or set to something else. script must be ready
# for those cases too.
#
# Algorithm:
# - Create TEMPDIR
# - Extract build-ids from coredump
# - For every build-id, check /usr/lib/debug/.build-id/XX/XXXX.debug
# and CACHEDIR/usr/lib/debug/.build-id/XX/XXXX.debug
# - If they all exist, exit 0
# - Using "yum provides /usr/lib/debug/.build-id/XX/XXXX.debug",
# figure out which debuginfo packages are needed
# - Download them using "yumdownloader PACKAGE..."
# - Unpack them with rpm2cpio | cpio to TEMPDIR
# - If CACHEDIR is specified, copy usr/lib/debug/.build-id/XX/XXXX.debug
# to CACHEDIR/usr/lib/debug/.build-id/XX/XXXX.debug and delete TEMPDIR
# - Report which XX/XXXX.debug are still missing.
#
# In the future, we may want to use a separate CACHEDIR (say, /var/cache/abrt-di)
# and use it with this gdb's command:
# set debug-file-directory /usr/lib/debug/.build-id:CACHEDIR/usr/lib/debug/.build-id
# but current gdb can't handle that.
# So, currently we are called with CACHEDIR set to "/".
# This is ugly, since it messes up /usr/lib/debug/.build-id over time
# by piling up debuginfos there without any means to control their amount,
# but it's the only way to make it work with current gdb.
#
# Output goes to GUI as debigunfo install log.
# "MISSING:xxxx" messages result in xxxx being prepended to backtrace
#
# Exitcodes:
# 0 - all debuginfos are installed
# 1 - not all debuginfos are installed
# 2+ - serious problem
...
--
vda
14 years, 6 months
[Crash-catcher] UI design: reporting a crash using the command line interface
by Karel Klic
Hi,
I am evaluating some ways how to properly implement reporting
a crash from the command line interface. User must be able to
describe the circumstances of the crash, edit the back trace,
and generally check which information is sent outside.
So the question is what happens when some user runs e.g.
$ abrt-cli --report df647e7771d228e2c281fafd8ca7047a2e34debd
So far, two ideas seems reasonable:
1) The application opens a text editor (specified by $EDITOR,
$VISUAL, or vi as a fallback) on a temporary file which contain
all the information (crash report).
However, there is a small problem with this approach:
abrt expects to receive information about crash
separated in certain fields (desc, backtrace, release etc.)
The temporary file contain all the fields merged, and the application
must separate them before sending the data over DBus.
I created an example crash report which shows how this problem could
be addressed. See attached report.txt.
2) Create ncurses interface with editable fields, just a single
screen for the purpose of crash reporting.
The former approach is probably better for experienced users,
just edit a file in your favourite editor and you are done.
Also `git commit` uses that. The latter approach is friendlier
to novice users. Nonetheless, inexperienced users will use
the abrt-applet and abrt-gui.
Which approach seems better to you?
Any ideas, suggestions?
Thanks,
Karel
--
Karel Klíč <kklic(a)redhat.com>
Developer, package maintainer
Office: +420 532 294 128
Mobile: +420 776 196 877
Red Hat Inc. http://cz.redhat.com
14 years, 6 months
[Crash-catcher] Draft retrace server [Re: gdb and debuginfofs: gdb needs need a --debuginfo-dir option]
by Jan Kratochvil
Hi Denys,
why is ABRT still pushing the symbols-at-client way when it was declared that
the retrace server is the right solution?
Quick-hacked one retrace server now:
http://dyn.jankratochvil.net/nethome/bin/retrace?view=co
(stdin->stdout, intended to run on a TCP listen port by xinetd)
Hopefully my RH machine can cope with the bugreporting load later.
It now produces:
23c77451cf6adff77fc1f5ee2a01d75de6511dda /bin/sleep
0340bfa9ae1a02c40b3477fede535accfc3df02b Missing: /usr/lib/debug/.build-id/03/40bfa9ae1a02c40b3477fede535accfc3df02b
2f831f25d6f61e530bcf0f510265a3c2d9de3f12 /lib64/librt-2.10.1.so
ec8dd400904ddfcac8b1c343263a790f977159dc /lib64/libc-2.10.1.so
271c0198aff5a26026d5e4ac56d13ad4b7346df6 /lib64/libpthread-2.10.1.so
520c2387a587cc5acfcf881e27dba1caaeab4b1f /lib64/ld-2.10.1.so
### retrace begin
GNU gdb (GDB) Fedora (6.8.50.20090302-38.fc11)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Core was generated by `sleep 1h'.
Program terminated with signal 11, Segmentation fault.
#0 0x00000036b5aa3f70 in __nanosleep_nocancel + 7 in section .text of /lib64/libc-2.10.1.so
#0 0x00000036b5aa3f70 in __nanosleep_nocancel + 7 in section .text of /lib64/libc-2.10.1.so
#1 0x00000000004037ab in rpl_nanosleep + 59 in section .text of /bin/sleep
#2 0x0010000000000000 in No symbol matches 0x0010000000000000.
#3 0x00007fff3dfe7988 in No symbol matches 0x00007fff3dfe7988.
#4 0x000000000015e0d8 in No symbol matches 0x000000000015e0d8.
#5 0x000000001176494e in No symbol matches 0x000000001176494e.
#6 0x0000000000000e10 in No symbol matches 0x0000000000000e10.
#7 0x0000000000000000 in No symbol matches 0x0000000000000000.
### retrace finish
The retrace itself works fine but still the backtrace is broken, it should
have been like:
#0 0x00000036b5aa3f70 in __nanosleep_nocancel in [...]
#1 0x00000000004037ab in rpl_nanosleep in [...]
#2 0x000000000040321b in xnanosleep in [...]
#3 0x000000000040176c in main in [...]
Just one can see a serious problem affecting also:
https://bugzilla.redhat.com/show_bug.cgi?id=525721
Try these two:
$ gdb -q -nx -ex "set debug-file-directory /_N" -ex "file /bin/sleep" -ex "core-file ./core.25895" -ex bt -ex q
#0 0x00000036b5aa3f70 in [...]
#1 0x00000000004037ab in [...]
#2 0x000000000040321b in [...]
#3 0x000000000040176c in [...]
[...]
$ gdb -q -nx -ex "set debug-file-directory /_N" -ex "core-file ./core.25895" -ex bt -ex q
#0 0x00000036b5aa3f70 in [...]
#1 0x00000000004037ab in [...]
#2 0x0010000000000000 in [...]
#3 0x00007fff3dfe7988 in [...]
#4 0x000000000015e0d8 in [...]
#5 0x000000001176494e in [...]
#6 0x0000000000000e10 in [...]
#7 0x0000000000000000 in [...]
[...]
The problem is that GDB needs for proper numeric backtrace the .eh_frame
section stored in the binary file itself. But if the client machine has no
/usr/lib/debug it has no way to map build-id to the binary file installed
there just according to the core file itself.
Temporarily it is therefore better to have the "file" command present in ABRT
for the Bug 525721. There needs to be found some better solution.
Thanks,
Jan
14 years, 6 months
[Crash-catcher] Plugin settings GUI
by Jiri Moskovcak
Hi,
I was thinking about how to make plugin settings more comfortable for
users and I got an idea, that we can add a function to plugin api
test_settings() which will test the settings (like login to bugzilla,
upload some file to ftp server, etc ...) because now, the only way to
figure, that settings are not working is to try to report a bug and wait
for the result.
Jirka
14 years, 6 months
Re: [Crash-catcher] gdb and debuginfofs: gdb needs need a --debuginfo-dir option
by Jan Kratochvil
On Fri, 09 Oct 2009 03:06:41 +0200, Denys Vlasenko wrote:
> There is a project, somewhat inactive, which basically mounts
> a network filesystem on /usr/lib/debug/.build-id so that gdb
> can use debuginfos from network. Homepage:
>
> https://fedoraproject.org/wiki/Features/DebuginfoFS
I do not think currently this project can bring any benefits. It has two
purposes:
(a) Reduce the size of the single loaded .debug file - this is right in the
future but due to various reasons GDB currently needs to read the whole
.debug file first to be able to extract the needed information from it.
GDB currently always reads the single whole .debug file so a download vs.
filesystem access do not make a difference.
(b) Download only specific file of the whole rpm package.
The use cases for the .debug files are:
(1) client bugreport: The client uses remote retrace server, no debuginfo
needed.
[Crash-catcher] Draft retrace server [...]
https://fedorahosted.org/pipermail/crash-catcher/2009-October/000052.html
(2) developer machine.
Only the combination (2)+(b) can benefit from the DebuginfoFS project. But
still I think the developer does not have such a problem to once download the
whole debuginfo rpms for his/her next months of debugging sessions. Also
(s)he will probably need various libraries related to the package being
developed, not just some single library from it. So it is even more
convenient to download it just once and not to wait for this or that .debug to
be loaded during the following interactive debugging sessions.
> we only need a gdb command-line option, say, --debuginfo-dir=DIR, which
> directs gdb to check that DIR for debuginfos too, in addition to standard
> one (/usr/lib/debug/.build-id).
There is no "in addition to" option, still you can use:
-ex "set debug-file-directory THE-PATHNAME-YOU-WANT"
One needs to be careful -ex options get executed only after the non-option
commandline arguments get loaded. So one rather needs to convert the
commandline arguments to the last "-ex" commands like:
gdb -ex "set debug-file-directory Q" X core.Y
into:
gdb -ex "set debug-file-directory Q" -ex "file X" -ex "core-file core.Y"
> but only one directory -
> maybe it makes sense to allow a list of directories.
Still I think a valid extension would be to support
-ex "set debug-file-directory DIR1:DIR2:DIR3"
, although still I would rather like to go the retrace server way.
Sometimes I was also using a very ugly solution of /tmp/subdir/debug
symlinking to /usr/lib/debug and containing/overriding some files there.
> Anyway, abrt does not need that, so it's theoretical...
>
> Jan, do you think you can implement it on gdb side?
Isn't the -ex "set debug-file-directory Q" option OK?
Thanks,
Jan
14 years, 6 months
