Version-Release number of selected component: findutils-4.5.11-4.fc20 Additional info: reporter: libreport-2.2.3 backtrace_rating: 4 cmdline: find ./ -type f -name libgobject-2.0.so crash_function: _dl_runtime_resolve executable: /usr/bin/find kernel: 3.16.3-200.fc20.x86_64 runlevel: N 5 type: CCpp Truncated backtrace: [New LWP 21258] warning: Could not load shared library symbols for 6 libraries, e.g. libselinux.so.1. Use the "info sharedlibrary" command to see the complete listing. Do you need "set solib-search-path" or "set sysroot"? Core was generated by `find ./ -type f -name libgobject-2.0.so'. Program terminated with signal SIGSEGV, Segmentation fault. #0 _dl_runtime_resolve () at ../sysdeps/x86_64/dl-trampoline.S:56 56 jmp *%r11 # Jump to function address. Thread 1 (LWP 21258): #0 _dl_runtime_resolve () at ../sysdeps/x86_64/dl-trampoline.S:56 No locals. #1 0x00000000004097d8 in now () at util.c:953 tv = {tv_sec = 0, tv_usec = 4233927} t = <optimized out> #2 set_option_defaults (p=0x62fcc0 <options>) at util.c:1007 No locals. #3 0x00000000004033cb in main (argc=6, argv=0x7fffa10d72b8) at ftsfind.c:679 end_of_leading_options = 0 eval_tree = <optimized out> From To Syms Read Shared Object Library No libselinux.so.1 No libm.so.6 No libc.so.6 No libdl.so.2 No libpcre.so.1 No libpthread.so.0 0x0000003bd5000b10 0x0000003bd5019c30 Yes /lib64/ld-linux-x86-64.so.2 No symbol "__abort_msg" in current context. No symbol "__glib_assert_msg" in current context. rax 0x1 1 rbx 0x62fcc0 6487232 rcx 0x0 0 rdx 0xf 15 rsi 0x0 0 rdi 0x7fffa10d7170 140735895400816 rbp 0x0 0x0 rsp 0x7fffa10d7168 0x7fffa10d7168 r8 0x7fffa10d7120 140735895400736 r9 0x1 1 r10 0x7fffa10d6f30 140735895400240 r11 0x3100300000000 862030001078272 r12 0x40351c 4207900 r13 0x6 6 r14 0x0 0 r15 0x0 0 rip 0x3bd501517e 0x3bd501517e <_dl_runtime_resolve+94> eflags 0x10202 [ IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 Dump of assembler code for function _dl_runtime_resolve: 0x0000003bd5015120 <+0>: sub $0x38,%rsp 0x0000003bd5015124 <+4>: mov %rax,(%rsp) 0x0000003bd5015128 <+8>: mov %rcx,0x8(%rsp) 0x0000003bd501512d <+13>: mov %rdx,0x10(%rsp) 0x0000003bd5015132 <+18>: mov %rsi,0x18(%rsp) 0x0000003bd5015137 <+23>: mov %rdi,0x20(%rsp) 0x0000003bd501513c <+28>: mov %r8,0x28(%rsp) 0x0000003bd5015141 <+33>: mov %r9,0x30(%rsp) 0x0000003bd5015146 <+38>: mov 0x40(%rsp),%rsi 0x0000003bd501514b <+43>: mov 0x38(%rsp),%rdi 0x0000003bd5015150 <+48>: callq 0x3bd500e650 <_dl_fixup> 0x0000003bd5015155 <+53>: mov %rax,%r11 0x0000003bd5015158 <+56>: mov 0x30(%rsp),%r9 0x0000003bd501515d <+61>: mov 0x28(%rsp),%r8 0x0000003bd5015162 <+66>: mov 0x20(%rsp),%rdi 0x0000003bd5015167 <+71>: mov 0x18(%rsp),%rsi 0x0000003bd501516c <+76>: mov 0x10(%rsp),%rdx 0x0000003bd5015171 <+81>: mov 0x8(%rsp),%rcx 0x0000003bd5015176 <+86>: mov (%rsp),%rax 0x0000003bd501517a <+90>: add $0x48,%rsp => 0x0000003bd501517e <+94>: jmpq *%r11 End of assembler dump.
Created attachment 945511 [details] File: backtrace
Created attachment 945512 [details] File: core_backtrace
Created attachment 945513 [details] File: dso_list
Created attachment 945514 [details] File: exploitable
Created attachment 945515 [details] File: limits
Created attachment 945516 [details] File: maps
Created attachment 945517 [details] File: proc_pid_status
The crash occurred in a call to gettimeofday(), which itself looks correct to me: static struct timespec now(void) { struct timespec retval; struct timeval tv; time_t t; if (0 == gettimeofday (&tv, NULL)) { retval.tv_sec = tv.tv_sec; retval.tv_nsec = tv.tv_usec * 1000; /* convert unit from microseconds to nanoseconds */ return retval; } t = time (NULL) assert (t != (time_t)-1); retval.tv_sec = t; retval.tv_nsec = 0; return retval; } I am switching the component to glibc.
The crash is actually in the resolver. This is the first call to gettimeofday, the PLT entry jumps to the lazy resolution function, which returns an invalid value, and then the resulting jump crashes. It looks like r11 is garbage in the backtrace which is why it crashes. There is no reason for r11 to be garbage in such a simple lookup process. Can you reproduce this?
(In reply to Carlos O'Donell from comment #9) > Can you reproduce this? No, sorry, I cannot. The next run was OK. I am quite surprised that find crashed. After all, find as a tool is quite established and has been around for many years.
Is findutils the only component that crashed like this on that machine?
(In reply to Kamil Dudka from comment #11) > Is findutils the only component that crashed like this on that machine? Yep.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
We still have no idea why this happens, and it could just be faulty hardware, cosmic rays, etc. Marking CLOSED/INSUFFICIENT_DATA. We'll keep an eye open to see if this happens again though.