Hi Sérgio,
It depends on what is your goal.
Do you want to fix the crash?
You can log in to FAF and check if there is a contact email or a comment. If there is not additional information, you can just wait until some opens a Bugzilla bug report.
Do you want to get rid of the notification?
You need to do that in Fedora Notifications app.
Or you can create a Bugzilla bug from the FAF report and close the bug as INSUFFCIENTDATA. FAF will synchorize the state of the FAF report with the Bugzilla bug, so the report will appear CLOSED. However, this way you will never receive a full Bugzilla bug report.
I've just started putting together a wiki page that should help maintainers to deal with ABRT. We should have done this several years ago, sorry about that:
https://fedoraproject.org/wiki/Automatic_Bug_Reporting_Tool
Regards,
Jakub
---------- Původní zpráva ----------
Od: SérgioBasto <sergio@xxxxxxxxxx>
Komu: devel@xxxxxxxxxxxxxxxxxxxxxxx
Datum: 29. 12. 2016 15:53:51
Předmět: Re: Interpreting FAF reports
BTW
I received ABRT report for package mlt has reached 100 occurrences
Packages: mlt
Function: QObject::disconnect(QObject const*, char const*, QObject
const*, char const*)
First occurrence: 2016-12-17
Type: core
Count: 100
URL: http://retrace.fedoraproject.org/faf/reports/bthash/43f48b90184f02e38f071ebff19966cdb25376cc/
what I can do ? I don't find anything related with mlt package !
On Qui, 2016-12-29 at 10:28 +0100, Florian Weimer wrote:
> Any idea what this is about?
>
> https://retrace.fedoraproject.org/faf/reports/1154372/
>
> To me that looks like a combination of several factors. First of
> all,
> the backtrace generation likely used incorrect debuginfo data
> because
> the backtrace is impossible. Stack corruption is unlikely to yield
> a
> relatively consistent backtrace—iconv and gconv match up, only the
> nscd
> and sunrpc functions in the middle do not make sense.
>
> I got lucky and build ID 25ea1fd961cb2f5a38172614365bd4c1aacb01a6
> refers
> to the current version of /usr/lib64/gconv/ISO8859-1.so, so I could
> do
> the disassembly manually.
>
> The crash is in the gconv function, at address 0xb50:
>
> b44: 49 39 d5 cmp %rdx,%r13
> b47: 72 2a jb b73 <gconv+0x3e3>
> b49: 48 89 d3 mov %rdx,%rbx
> b4c: 48 83 c0 01 add $0x1,%rax
> b50: 0f b6 50 ff movzbl -0x1(%rax),%edx
> b54: 48 39 c5 cmp %rax,%rbp
> b57: 89 53 fc mov %edx,-0x4(%rbx)
> b5a: 75 e4 jne b40 <gconv+0x3b0>
> b5c: 41 bb 04 00 00 00 mov $0x4,%r11d
> b62: e9 1a ff ff ff jmpq a81 <gconv+0x2f1>
> b67: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
>
> Experimentation with GDB shows that this is in the part which
> converts
> from ISO-8859-1, and it is the load from the input buffer. A crash
> at
> this point is impossible because we have a bounds check in the gconv
> implementation framework before this load.
>
> However, iconv (the command) maps the input file, and something is
> truncating that file, causing the SIGBUS error. This is just how
> mmap
> works in POSIX, unfortunately.
>
> Is there a way to discover who is submitting these crash reports and
> what they are trying to do? I wonder if we should remove the mmap
> from
> the iconv command, so that we would not crash in this case.
>
> Florian
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
--
Sérgio M. B.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
