On Thu, 29 Dec 2016 14:52:29 +0000, Sérgio Basto wrote: In a few past cases, some people have hacked local code that caused crashes through plugins or dependencies.

On Seg, 2017-01-02 at 19:21 +0100, jfilak(a)fedoraproject.org wrote: 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 ... Od: SérgioBasto <sergio(a)serjux.com&gt; Komu: devel(a)lists.fedoraproject.org Datum: 29. 12. 2016 15:53:51 Předmět: Re: Interpreting FAF reports 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.

Isn't this related to no free disk space? I've seen some strange mmap related crashes when a process mmaped a sparse file and disk ran out of free space. Anyway, please do let me know what additional information would help you to resolve the issue. Please bare in mind that FAF report must be anonymous and automatically submitted. Regards, Jakub ---------- Původní zpráva ---------- Od: Florian Weimer <fweimer(a)redhat.com&gt; Komu: Development discussions related to Fedora <devel(a)lists.fedoraproject. org> Datum: 29. 12. 2016 10:29:37 Předmět: Interpreting FAF reports "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 "