Version-Release number of selected component: epiphany-runtime-3.16.1-1.fc22 Additional info: reporter: libreport-2.5.1 backtrace_rating: 4 cmdline: epiphany http://i.imgur.com/TOI65jx.png crash_function: pthread_cond_timedwait@@GLIBC_2.3.2 executable: /usr/bin/epiphany global_pid: 5445 kernel: 4.0.4-301.fc22.x86_64 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 20 (5 frames) #0 pthread_cond_timedwait@@GLIBC_2.3.2 at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 #1 __gthread_cond_timedwait at /usr/include/c++/5.1.1/x86_64-redhat-linux/bits/gthr-default.h:871 #2 __wait_until_impl<std::chrono::duration<long, std::ratio<1l, 1000000000l> > > at /usr/include/c++/5.1.1/condition_variable:165 #3 wait_until<std::chrono::duration<long, std::ratio<1l, 1000000000l> > > at /usr/include/c++/5.1.1/condition_variable:105 #4 wait_until<std::unique_lock<bmalloc::Mutex>, std::chrono::_V2::system_clock, std::chrono::duration<long, std::ratio<1l, 1000000000l> > > at /usr/include/c++/5.1.1/condition_variable:273
Created attachment 1032472 [details] File: backtrace
Created attachment 1032473 [details] File: cgroup
Created attachment 1032474 [details] File: core_backtrace
Created attachment 1032475 [details] File: dso_list
Created attachment 1032476 [details] File: environ
Created attachment 1032477 [details] File: limits
Created attachment 1032478 [details] File: maps
Created attachment 1032479 [details] File: mountinfo
Created attachment 1032480 [details] File: namespaces
Created attachment 1032481 [details] File: open_fds
Created attachment 1032482 [details] File: proc_pid_status
Created attachment 1032483 [details] File: var_log_messages
Um, this is a real bug in Ephy that we need to fix, but I think the more serious bug here is that the title of the bug and provided backtrace are for the wrong thread, so something here has got ABRT very confused. There's no crash in pthread_cond_timedwait, the crash is in ephy_location_entry_set_location.
I've reported the Epiphany crash upstream as https://bugzilla.gnome.org/show_bug.cgi?id=750161 so this bug can be used solely for the ABRT issue now.
Frame #5 causes satyr to stop parsing the backtrace and satyr does not return an error but returns a partially parsed gdb stacktrace with a single thread. In such a case, where a gdb stacktrace has only one thread, satyr uses the thread as crash thread. That all lead me into a conclusion that satyr fails to recognize the crash thread, but the true is that satyr fails to parse C++ template arguments.
I have opened a pull request that should fix the bug: https://github.com/abrt/satyr/pull/230
libreport-2.6.1-1.fc22,abrt-2.6.1-1.fc22,satyr-0.19-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/libreport-2.6.1-1.fc22,abrt-2.6.1-1.fc22,satyr-0.19-1.fc22
Package libreport-2.6.1-1.fc22, abrt-2.6.1-1.fc22, satyr-0.19-1.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libreport-2.6.1-1.fc22 abrt-2.6.1-1.fc22 satyr-0.19-1.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-11434/libreport-2.6.1-1.fc22,abrt-2.6.1-1.fc22,satyr-0.19-1.fc22 then log in and leave karma (feedback).
libreport-2.6.1-1.fc22, abrt-2.6.1-1.fc22, satyr-0.19-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.