ignored problems in ABRT
by Jiri Moskovcak
Responding to your questions from IRC:
<kparal> if I mark some crash as "Ignore forever", how do I cancel that?
<kparal> how do I list of ignored tracebacks?
<kparal> *see a list of
- ABRT doesn't use tracebacks, it uses the path to the existing problem
+ traceback hashes to mark the ignored problems, you can look into
$HOME/.cache/abrt/ignored_problems
--Jirka
10 years, 6 months
correlating static analysis results with known crashes
by Martin Milata
Hello,
I've implemented a proof-of-concept of an analysis that tries to pair
static analysis results with known crashes based on the source code
locations, as outlined in [1].
The code extends David Malcolm's mock-with-analysis and is available at
[2]. The machinery for generating static analysis results is unchanged
apart from a few fixes needed for it to run on Fedora 19. The script
make-simple-report.py was extended to accept second argument with crash
reports from FAF server, and the matching crashes are referenced in the
generated reports. There is currently no way to obtain the file with
crashes automatically, I got it from the server administrator.
I ran the analysis on following packages:
* tracker-0.16.2-1.fc19
* evolution-3.6.4-3.fc18
* gnome-shell-3.6.3.1-1.fc18
* nautilus-3.6.3-4.fc18
* python-2.7.3-13.fc18
* rhythmbox-2.98-4.fc18
Tracker was chosen arbitrarily, the rest of the builds are those that
have the highest number of distinct crashes. The results can be viewed
at [3] and given that they were obtained from packages with the highest
number of collected crashes, they don't seem to be very encouraging.
There are only three [4,5,6] matches that are not obvious false
positives. All the data needed to reproduce this should be available at
[7].
There are two main causes of false positives:
* The code considers all static analysis results, not only those from
tests for behaviour that would result in a crash at runtime.
* It considers all stack frames in a crash, not just the topmost one.
As a side note, all three matches come from the clang static analyzer,
which for some reason fails for quite a lot of source files.
What do you think?
Thanks,
Martin
[1] https://lists.fedoraproject.org/pipermail/firehose-devel/2013-October/000...
[2] https://github.com/mmilata/mock-with-analysis/tree/crash-correlation
[3] http://mmilata.fedorapeople.org/firehose-crash-correlation/
[4] http://mmilata.fedorapeople.org/firehose-crash-correlation/nautilus/sourc...
[5] http://mmilata.fedorapeople.org/firehose-crash-correlation/nautilus/sourc...
[6] http://mmilata.fedorapeople.org/firehose-crash-correlation/python/sources...
[7] http://mmilata.fedorapeople.org/firehose-crash-correlation.tar.xz
10 years, 6 months
rasdaemon and abrt
by 李俊良
Hi, all
Fedora 19 has a tool named rasdaemon. From its maintainer, Mauro, I know
that rasdaemon and ABRT will work together. But I don't know much about
that. Would anyone introduce something about rasdaemon and ABRT?
10 years, 7 months
Better fix for "huge backtrace" problem?
by Denys Vlasenko
https://bugzilla.redhat.com/show_bug.cgi?id=995889
Synopsis:
--- Running report_uReport ---
Generating core_backtrace
Generating backtrace
Backtrace is too big (33561281 bytes), reducing depth to 512
Backtrace is too big (33561281 bytes), reducing depth to 256
Backtrace is too big (33561281 bytes), reducing depth to 128
Backtrace is too big (33561281 bytes), reducing depth to 64
Backtrace is too big (33555685 bytes), reducing depth to 64
Backtrace is too big (33555461 bytes), reducing depth to 64
Backtrace is too big (33555461 bytes), reducing depth to 32
Error: Line 15, column 0: "Thread" header expected
('report_uReport' exited with 1)
The currently implemented solution is to remove -ex disassemble"
gdb command"
args[18] = (char*)"-ex";
args[19] = (char*)"disassemble";
args[20] = NULL;
...
+ /* Disable -ex disassemble, output might be huge preventing backtrace generation */
+ args[18] = NULL;
+ args[19] = NULL;
+
But... disasm sometimes does immediately show the problem...
How about just reducing of disassembly range? Instead
of removing the command, how about:
args[19] = (char*)"disassemble $pc, +64";
?
10 years, 7 months