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
