On Seg, 2017-01-02 at 19:21 +0100, jfilak(a)fedoraproject.org wrote:
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.
yes I want at least understand the issue and maybe fix it , I just
login and still have any bug associated, meanwhile count is over 200
...
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(a)serjux.com>
Komu: devel(a)lists.fedoraproject.org
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/43f48b90184...
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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> > > _______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Sérgio M. B.