Version-Release number of selected component: nautilus-3.10.1-3.fc20 Additional info: reporter: libreport-2.2.0 backtrace_rating: 4 cmdline: nautilus --new-window crash_function: wherePathSatisfiesOrderBy executable: /usr/bin/nautilus kernel: 3.13.6-200.fc20.i686+PAE runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #0 wherePathSatisfiesOrderBy at sqlite3.c:114178 #1 wherePathSolver at sqlite3.c:114575 #2 sqlite3WhereBegin at sqlite3.c:114969 #3 sqlite3Select at sqlite3.c:104775 #4 yy_reduce at sqlite3.c:117722 #5 sqlite3Parser at sqlite3.c:53224 #6 sqlite3RunParser at sqlite3.c:119590 #7 sqlite3Prepare at sqlite3.c:99779 #8 sqlite3LockAndPrepare at sqlite3.c:99871 #9 tracker_db_interface_create_statement at tracker-db-interface-sqlite.c:1367
Created attachment 873800 [details] File: backtrace
Created attachment 873801 [details] File: cgroup
Created attachment 873802 [details] File: core_backtrace
Created attachment 873803 [details] File: dso_list
Created attachment 873804 [details] File: environ
Created attachment 873805 [details] File: exploitable
Created attachment 873806 [details] File: limits
Created attachment 873807 [details] File: maps
Created attachment 873808 [details] File: open_fds
Created attachment 873809 [details] File: proc_pid_status
Created attachment 873810 [details] File: var_log_messages
This appears to be easy to reproduce. On a fresh Fedora 20 install, updated to the latest software, search for anything in Nautilus (just press a key or two).
I can't reproduce this on my F20 test box - tried several searches in nautilus, all seemed to work OK...
Well, the bug can be triggered with the following method: 1. mkdir aaaaa && nautilus aaaaa 2. Switch to nautilus and type "aaaaa". 3. Files crashes. Just in case it helps.
Delete file home/.cache/tracker/meta.db-wal This work for me. The problem returns after restart.
I can easily reproduce this by going to my large music folder, typing a subfolder name (so the search dialog is displayed) and clicking some folder name. Running nautilus under XFCE on Fedora 20, in this case: Program received signal SIGSEGV, Segmentation fault. 0x414b5cd2 in wherePathSatisfiesOrderBy (pWInfo=pWInfo@entry=0x86e2748, wctrlFlags=wctrlFlags@entry=512, nLoop=2, pLast=0x87b2d88, pRevMask=pRevMask@entry=0xbfffded0, pPath=0x8ad6708, pOrderBy=<optimized out>, pOrderBy=<optimized out>) at sqlite3.c:114178 114178 }else if( (pIndex = pLoop->u.btree.pIndex)==0 || pIndex->bUnordered ){ (gdb) thread apply all bt Thread 9 (Thread 0xae655b40 (LWP 5752)): #0 0xb7fff424 in __kernel_vsyscall () #1 0x496e7b76 in pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_timedwait.S:245 #2 0x498f4500 in g_cond_wait_until (cond=cond@entry=0x820b168, mutex=mutex@entry=0x820b160, end_time=8052285095) at gthread-posix.c:870 #3 0x49880b61 in g_async_queue_pop_intern_unlocked (queue=0x820b160, wait=wait@entry=1, end_time=8052285095) at gasyncqueue.c:424 #4 0x49881394 in g_async_queue_timeout_pop_unlocked (queue=0xdff41ea7, timeout=1) at gasyncqueue.c:572 #5 0x498d69d7 in g_thread_pool_wait_for_new_task (pool=0x8203160) at gthreadpool.c:264 #6 g_thread_pool_thread_proxy (data=0x8203160) at gthreadpool.c:298 #7 0x498d5ebb in g_thread_proxy (data=0x8255320) at gthread.c:798 #8 0x496e3d8a in start_thread (arg=0xae655b40) at pthread_create.c:309 #9 0x49614a0e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129 Thread 5 (Thread 0xb5c71b40 (LWP 5738)): #0 0xb7fff424 in __kernel_vsyscall () #1 0x496083eb in poll () at ../sysdeps/unix/syscall-template.S:81 #2 0x498bdf9c in poll (__timeout=__timeout@entry=290, __nfds=__nfds@entry=2, __fds=__fds@entry=0x824d5e8) at /usr/include/bits/poll2.h:46 #3 g_poll (fds=fds@entry=0x824d5e8, nfds=nfds@entry=2, timeout=timeout@entry=290) at gpoll.c:132 #4 0x498ae8a0 in g_main_context_poll (priority=2147483647, n_fds=2, fds=0x824d5e8, timeout=290, context=0x82433a8) at gmain.c:4007 #5 g_main_context_iterate (context=context@entry=0x82433a8, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3708 #6 0x498ae9e9 in g_main_context_iteration (context=0x82433a8, may_block=may_block@entry=1) at gmain.c:3774 #7 0x498aea76 in glib_worker_main (data=0x0) at gmain.c:5473 #8 0x498d5ebb in g_thread_proxy (data=0x8255200) at gthread.c:798 #9 0x496e3d8a in start_thread (arg=0xb5c71b40) at pthread_create.c:309 #10 0x49614a0e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129 Thread 4 (Thread 0xb69ffb40 (LWP 5737)): #0 0xb7fff424 in __kernel_vsyscall () ---Type <return> to continue, or q <return> to quit--- #1 0x496083eb in poll () at ../sysdeps/unix/syscall-template.S:81 #2 0x498bdf9c in poll (__timeout=__timeout@entry=25000, __nfds=__nfds@entry=1, __fds=__fds@entry=0xb6000c68) at /usr/include/bits/poll2.h:46 #3 g_poll (fds=fds@entry=0xb6000c68, nfds=nfds@entry=1, timeout=timeout@entry=25000) at gpoll.c:132 #4 0x498ae8a0 in g_main_context_poll (priority=2147483647, n_fds=1, fds=0xb6000c68, timeout=25000, context=0x820f120) at gmain.c:4007 #5 g_main_context_iterate (context=context@entry=0x820f120, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3708 #6 0x498ae9e9 in g_main_context_iteration (context=context@entry=0x820f120, may_block=may_block@entry=1) at gmain.c:3774 #7 0xb7ff6180 in dconf_gdbus_worker_thread (user_data=0x820f120) at dconf-gdbus-thread.c:81 #8 0x498d5ebb in g_thread_proxy (data=0x81c5e60) at gthread.c:798 #9 0x496e3d8a in start_thread (arg=0xb69ffb40) at pthread_create.c:309 #10 0x49614a0e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129 Thread 2 (Thread 0xb7dc7b40 (LWP 5735)): #0 0xb7fff424 in __kernel_vsyscall () #1 0x496083eb in poll () at ../sysdeps/unix/syscall-template.S:81 #2 0x498bdf9c in poll (__timeout=__timeout@entry=0, __nfds=__nfds@entry=1, __fds=__fds@entry=0xb7dc6eb4) at /usr/include/bits/poll2.h:46 #3 g_poll (fds=fds@entry=0xb7dc6eb4, nfds=nfds@entry=1, timeout=timeout@entry=0) at gpoll.c:132 #4 0x49bd561a in g_socket_condition_check (socket=socket@entry=0x81e48f0, condition=condition@entry=G_IO_IN) at gsocket.c:3487 #5 0x49c40892 in _g_socket_read_with_control_messages (socket=0x81e48f0, buffer=0xb740a110, count=56, messages=messages@entry=0x81e6b20, num_messages=num_messages@entry=0x81e6b24, io_priority=io_priority@entry=0, cancellable=0x81d4d90, callback=callback@entry=0x49c42900 <_g_dbus_worker_do_read_cb>, user_data=user_data@entry=0x81e6ad0) at gdbusprivate.c:197 #6 0x49c409ce in _g_dbus_worker_do_read_unlocked (worker=worker@entry=0x81e6ad0) at gdbusprivate.c:861 #7 0x49c43024 in _g_dbus_worker_do_read_cb (input_stream=0x81e48f0, res=0x84caa08, user_data=0x81e6ad0) at gdbusprivate.c:745 #8 0x49bd2c95 in g_simple_async_result_complete (simple=0x84caa08) at gsimpleasyncresult.c:777 #9 0x49c40779 in _g_socket_read_with_control_messages_ready (socket=0x81e48f0, condition=G_IO_IN, user_data=0xb7405fd8) at gdbusprivate.c:163 #10 0x49bd3c32 in socket_source_dispatch (source=source@entry=0xb748cbc0, callback=0x49c40690 <_g_socket_read_with_control_messages_ready>, user_data=0xb7405fd8) at gsocket.c:3264 #11 0x498ae556 in g_main_dispatch (context=0x81e6ff0) at gmain.c:3066 #12 g_main_context_dispatch (context=context@entry=0x81e6ff0) at gmain.c:3642 ---Type <return> to continue, or q <return> to quit--- #13 0x498ae920 in g_main_context_iterate (context=0x81e6ff0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3713 #14 0x498aedc3 in g_main_loop_run (loop=0x81e6fb8) at gmain.c:3907 #15 0x49c40acb in gdbus_shared_thread_func (user_data=0x81e6fd8) at gdbusprivate.c:278 #16 0x498d5ebb in g_thread_proxy (data=0x81c59b0) at gthread.c:798 #17 0x496e3d8a in start_thread (arg=0xb7dc7b40) at pthread_create.c:309 #18 0x49614a0e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129 Thread 1 (Thread 0xb7fc88c0 (LWP 5727)): #0 0x414b5cd2 in wherePathSatisfiesOrderBy (pWInfo=pWInfo@entry=0x86e2748, wctrlFlags=wctrlFlags@entry=512, nLoop=2, pLast=0x87b2d88, pRevMask=pRevMask@entry=0xbfffded0, pPath=0x8ad6708, pOrderBy=<optimized out>, pOrderBy=<optimized out>) at sqlite3.c:114178 #1 0x414b69a7 in wherePathSolver (pWInfo=pWInfo@entry=0x86e2748, nRowEst=nRowEst@entry=44) at sqlite3.c:114575 #2 0x414cbe61 in sqlite3WhereBegin (pParse=pParse@entry=0x8ada460, pTabList=pTabList@entry=0x879db70, pWhere=pWhere@entry=0x87b2708, pOrderBy=pOrderBy@entry=0x87b2688, pResultSet=0x87b8488, wctrlFlags=1024, iIdxCur=iIdxCur@entry=0) at sqlite3.c:114969 #3 0x414cf59b in sqlite3Select (pParse=pParse@entry=0x8ada460, p=<optimized out>, pDest=pDest@entry=0xbfffe1c0) at sqlite3.c:104775 #4 0x414e62dc in yy_reduce (yyruleno=111, yypParser=0x8ad5934) at sqlite3.c:117722 #5 sqlite3Parser (yyp=yyp@entry=0x8ad5908, yymajor=yymajor@entry=1, yyminor=..., pParse=pParse@entry=0x8ada460) at sqlite3.c:53224 #6 0x414e8cb4 in sqlite3RunParser (pParse=pParse@entry=0x8ada460, zSql=zSql@entry=0x8ad9f58 "SELECT DISTINCT (SELECT \"nie:url\" FROM \"nie:DataObject\" WHERE ID = \"1_u\") COLLATE TRACKER AS \"2_u\", CAST (\"urn_u_rank\" AS TEXT) AS \"3_u\", COALESCE(SparqlFormatTime ((SELECT \"nfo:fileLastModified\" FROM"..., pzErrMsg=pzErrMsg@entry=0xbfffe294) at sqlite3.c:119590 #7 0x414e92e4 in sqlite3Prepare (db=db@entry=0x87789b8, zSql=zSql@entry=0x8ad9f58 "SELECT DISTINCT (SELECT \"nie:url\" FROM \"nie:DataObject\" WHERE ID = \"1_u\") COLLATE TRACKER AS \"2_u\", CAST (\"urn_u_rank\" AS TEXT) AS \"3_u\", COALESCE(SparqlFormatTime ((SELECT \"nfo:fileLastModified\" FROM"..., nBytes=nBytes@entry=-1, saveSqlFlag=saveSqlFlag@entry=1, pReprepare=pReprepare@entry=0x0, ppStmt=ppStmt@entry=0xbfffe338, pzTail=pzTail@entry=0x0) at sqlite3.c:99779 #8 0x414e9606 in sqlite3LockAndPrepare (db=0x87789b8, zSql=0x8ad9f58 "SELECT DISTINCT (SELECT \"nie:url\" FROM \"nie:DataObject\" WHERE ID = \"1_u\") COLLATE TRACKER AS \"2_u\", CAST (\"urn_u_rank\" AS TEXT) AS \"3_u\", COALESCE(SparqlFormatTime ((SELECT \"nfo:fileLastModified\" FROM"..., nBytes=-1, saveSqlFlag=1, pOld=0x0, ppStmt=0xbfffe338, pzTail=0x0) at sqlite3.c:99871 ---Type <return> to continue, or q <return> to quit--- #9 0x4165af2f in tracker_db_interface_create_statement () from /usr/lib/tracker-0.16/libtracker-data.so.0 #10 0x41632655 in tracker_sparql_query_exec_sql_cursor () from /usr/lib/tracker-0.16/libtracker-data.so.0 #11 0x4163784a in tracker_sparql_query_execute_cursor () from /usr/lib/tracker-0.16/libtracker-data.so.0 #12 0x415f4193 in tracker_direct_connection_query_unlocked.isra.2 () from /lib/libtracker-sparql-0.16.so.0 #13 0x415f4525 in tracker_direct_connection_real_query_async_co () from /lib/libtracker-sparql-0.16.so.0 #14 0x415ea7a0 in tracker_sparql_connection_query_async () from /lib/libtracker-sparql-0.16.so.0 #15 0x415e4dcb in tracker_sparql_backend_real_query_async_co () from /lib/libtracker-sparql-0.16.so.0 #16 0x415ea7a0 in tracker_sparql_connection_query_async () from /lib/libtracker-sparql-0.16.so.0 #17 0x0812db83 in nautilus_search_engine_tracker_start () #18 0x0811ec4f in nautilus_search_provider_start () #19 0x0811efa5 in search_engine_start_real () #20 0x0811ec4f in nautilus_search_provider_start () #21 0x0811d250 in start_search () #22 0x080f3f79 in nautilus_directory_file_monitor_add () #23 0x080a63da in finish_loading_if_all_metadata_loaded () #24 0x080a6552 in metadata_for_files_in_directory_ready_callback () #25 0x0811cb36 in search_callback_invoke_and_destroy () #26 0x080f3e01 in nautilus_directory_call_when_ready () #27 0x080b2824 in load_directory () #28 0x080b29b0 in nautilus_view_load_location () #29 0x080b67fe in load_new_location () #30 0x080b7744 in create_content_view () #31 0x080baa63 in got_file_info_for_view_selection_callback () #32 0x0811e89d in search_directory_file_call_when_ready () #33 0x0810d4c1 in nautilus_file_call_when_ready () #34 0x080b8833 in begin_location_change () #35 0x080b8d93 in nautilus_window_slot_open_location_full () #36 0x080ba327 in query_editor_changed_callback () #37 0x4999d4e6 in ffi_call_SYSV () at ../src/x86/sysv.S:65 #38 0x4999d26c in ffi_call (cif=<optimized out>, cif@entry=0xbfffeb34, fn=<optimized out>, rvalue=<optimized out>, avalue=<optimized out>, avalue@entry=0xbfffea80) at ../src/x86/ffi.c:411 #39 0x499b00a1 in g_cclosure_marshal_generic (closure=0x846f540, return_gvalue=0x0, n_param_values=3, param_values=0xbfffecb0, invocation_hint=0xbfffec58, marshal_data=0x0) at gclosure.c:1454 #40 0x499af7de in g_closure_invoke (closure=0x846f540, return_value=return_value@entry=0x0, n_param_values=3, ---Type <return> to continue, or q <return> to quit--- param_values=param_values@entry=0xbfffecb0, invocation_hint=invocation_hint@entry=0xbfffec58) at gclosure.c:777 #41 0x499c256e in signal_emit_unlocked_R (node=node@entry=0x83bdd20, detail=detail@entry=0, instance=0x8326360, emission_return=emission_return@entry=0x0, instance_and_params=0xbfffecb0) at gsignal.c:3586 #42 0x499ca3c1 in g_signal_emit_valist (instance=instance@entry=0x8326360, signal_id=signal_id@entry=334, detail=detail@entry=0, var_args=0xbfffee14 "", var_args@entry=0xbfffee0c "@Zx\b\001") at gsignal.c:3330 #43 0x499ca654 in g_signal_emit (instance=0x8326360, signal_id=334, detail=0) at gsignal.c:3386 #44 0x0809dc31 in nautilus_query_editor_changed_force.constprop.3 () #45 0x0809dc68 in typing_timeout_cb () #46 0x498af262 in g_timeout_dispatch (source=source@entry=0x8519408, callback=0x809dc40 <typing_timeout_cb>, user_data=0x8326360) at gmain.c:4451 #47 0x498ae556 in g_main_dispatch (context=0x81dd0a8) at gmain.c:3066 #48 g_main_context_dispatch (context=context@entry=0x81dd0a8) at gmain.c:3642 #49 0x498ae920 in g_main_context_iterate (context=context@entry=0x81dd0a8, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3713 #50 0x498ae9e9 in g_main_context_iteration (context=0x81dd0a8, context@entry=0x0, may_block=may_block@entry=1) at gmain.c:3774 #51 0x49c067ac in g_application_run (application=0x81c50e0, argc=1, argv=0xbffff054) at gapplication.c:1635 #52 0x08067b3d in main () (gdb) thread apply all bt Thread 9 (Thread 0xae655b40 (LWP 5752)): #0 0xb7fff424 in __kernel_vsyscall () #1 0x496e7b76 in pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_timedwait.S:245 #2 0x498f4500 in g_cond_wait_until (cond=cond@entry=0x820b168, mutex=mutex@entry=0x820b160, end_time=8052285095) at gthread-posix.c:870 #3 0x49880b61 in g_async_queue_pop_intern_unlocked (queue=0x820b160, wait=wait@entry=1, end_time=8052285095) at gasyncqueue.c:424 #4 0x49881394 in g_async_queue_timeout_pop_unlocked (queue=0xdff41ea7, timeout=1) at gasyncqueue.c:572 #5 0x498d69d7 in g_thread_pool_wait_for_new_task (pool=0x8203160) at gthreadpool.c:264 #6 g_thread_pool_thread_proxy (data=0x8203160) at gthreadpool.c:298 #7 0x498d5ebb in g_thread_proxy (data=0x8255320) at gthread.c:798 #8 0x496e3d8a in start_thread (arg=0xae655b40) at pthread_create.c:309 #9 0x49614a0e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129 Thread 5 (Thread 0xb5c71b40 (LWP 5738)): #0 0xb7fff424 in __kernel_vsyscall () #1 0x496083eb in poll () at ../sysdeps/unix/syscall-template.S:81 #2 0x498bdf9c in poll (__timeout=__timeout@entry=290, __nfds=__nfds@entry=2, __fds=__fds@entry=0x824d5e8) at /usr/include/bits/poll2.h:46 #3 g_poll (fds=fds@entry=0x824d5e8, nfds=nfds@entry=2, timeout=timeout@entry=290) at gpoll.c:132 #4 0x498ae8a0 in g_main_context_poll (priority=2147483647, n_fds=2, fds=0x824d5e8, timeout=290, context=0x82433a8) at gmain.c:4007 #5 g_main_context_iterate (context=context@entry=0x82433a8, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3708 #6 0x498ae9e9 in g_main_context_iteration (context=0x82433a8, may_block=may_block@entry=1) at gmain.c:3774 #7 0x498aea76 in glib_worker_main (data=0x0) at gmain.c:5473 #8 0x498d5ebb in g_thread_proxy (data=0x8255200) at gthread.c:798 #9 0x496e3d8a in start_thread (arg=0xb5c71b40) at pthread_create.c:309 #10 0x49614a0e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129 Thread 4 (Thread 0xb69ffb40 (LWP 5737)): #0 0xb7fff424 in __kernel_vsyscall () ---Type <return> to continue, or q <return> to quit--- #1 0x496083eb in poll () at ../sysdeps/unix/syscall-template.S:81 #2 0x498bdf9c in poll (__timeout=__timeout@entry=25000, __nfds=__nfds@entry=1, __fds=__fds@entry=0xb6000c68) at /usr/include/bits/poll2.h:46 #3 g_poll (fds=fds@entry=0xb6000c68, nfds=nfds@entry=1, timeout=timeout@entry=25000) at gpoll.c:132 #4 0x498ae8a0 in g_main_context_poll (priority=2147483647, n_fds=1, fds=0xb6000c68, timeout=25000, context=0x820f120) at gmain.c:4007 #5 g_main_context_iterate (context=context@entry=0x820f120, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3708 #6 0x498ae9e9 in g_main_context_iteration (context=context@entry=0x820f120, may_block=may_block@entry=1) at gmain.c:3774 #7 0xb7ff6180 in dconf_gdbus_worker_thread (user_data=0x820f120) at dconf-gdbus-thread.c:81 #8 0x498d5ebb in g_thread_proxy (data=0x81c5e60) at gthread.c:798 #9 0x496e3d8a in start_thread (arg=0xb69ffb40) at pthread_create.c:309 #10 0x49614a0e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129 Thread 2 (Thread 0xb7dc7b40 (LWP 5735)): #0 0xb7fff424 in __kernel_vsyscall () #1 0x496083eb in poll () at ../sysdeps/unix/syscall-template.S:81 #2 0x498bdf9c in poll (__timeout=__timeout@entry=0, __nfds=__nfds@entry=1, __fds=__fds@entry=0xb7dc6eb4) at /usr/include/bits/poll2.h:46 #3 g_poll (fds=fds@entry=0xb7dc6eb4, nfds=nfds@entry=1, timeout=timeout@entry=0) at gpoll.c:132 #4 0x49bd561a in g_socket_condition_check (socket=socket@entry=0x81e48f0, condition=condition@entry=G_IO_IN) at gsocket.c:3487 #5 0x49c40892 in _g_socket_read_with_control_messages (socket=0x81e48f0, buffer=0xb740a110, count=56, messages=messages@entry=0x81e6b20, num_messages=num_messages@entry=0x81e6b24, io_priority=io_priority@entry=0, cancellable=0x81d4d90, callback=callback@entry=0x49c42900 <_g_dbus_worker_do_read_cb>, user_data=user_data@entry=0x81e6ad0) at gdbusprivate.c:197 #6 0x49c409ce in _g_dbus_worker_do_read_unlocked (worker=worker@entry=0x81e6ad0) at gdbusprivate.c:861 #7 0x49c43024 in _g_dbus_worker_do_read_cb (input_stream=0x81e48f0, res=0x84caa08, user_data=0x81e6ad0) at gdbusprivate.c:745 #8 0x49bd2c95 in g_simple_async_result_complete (simple=0x84caa08) at gsimpleasyncresult.c:777 #9 0x49c40779 in _g_socket_read_with_control_messages_ready (socket=0x81e48f0, condition=G_IO_IN, user_data=0xb7405fd8) at gdbusprivate.c:163 #10 0x49bd3c32 in socket_source_dispatch (source=source@entry=0xb748cbc0, callback=0x49c40690 <_g_socket_read_with_control_messages_ready>, user_data=0xb7405fd8) at gsocket.c:3264 #11 0x498ae556 in g_main_dispatch (context=0x81e6ff0) at gmain.c:3066 #12 g_main_context_dispatch (context=context@entry=0x81e6ff0) at gmain.c:3642 ---Type <return> to continue, or q <return> to quit--- #13 0x498ae920 in g_main_context_iterate (context=0x81e6ff0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3713 #14 0x498aedc3 in g_main_loop_run (loop=0x81e6fb8) at gmain.c:3907 #15 0x49c40acb in gdbus_shared_thread_func (user_data=0x81e6fd8) at gdbusprivate.c:278 #16 0x498d5ebb in g_thread_proxy (data=0x81c59b0) at gthread.c:798 #17 0x496e3d8a in start_thread (arg=0xb7dc7b40) at pthread_create.c:309 #18 0x49614a0e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129 Thread 1 (Thread 0xb7fc88c0 (LWP 5727)): #0 0x414b5cd2 in wherePathSatisfiesOrderBy (pWInfo=pWInfo@entry=0x86e2748, wctrlFlags=wctrlFlags@entry=512, nLoop=2, pLast=0x87b2d88, pRevMask=pRevMask@entry=0xbfffded0, pPath=0x8ad6708, pOrderBy=<optimized out>, pOrderBy=<optimized out>) at sqlite3.c:114178 #1 0x414b69a7 in wherePathSolver (pWInfo=pWInfo@entry=0x86e2748, nRowEst=nRowEst@entry=44) at sqlite3.c:114575 #2 0x414cbe61 in sqlite3WhereBegin (pParse=pParse@entry=0x8ada460, pTabList=pTabList@entry=0x879db70, pWhere=pWhere@entry=0x87b2708, pOrderBy=pOrderBy@entry=0x87b2688, pResultSet=0x87b8488, wctrlFlags=1024, iIdxCur=iIdxCur@entry=0) at sqlite3.c:114969 #3 0x414cf59b in sqlite3Select (pParse=pParse@entry=0x8ada460, p=<optimized out>, pDest=pDest@entry=0xbfffe1c0) at sqlite3.c:104775 #4 0x414e62dc in yy_reduce (yyruleno=111, yypParser=0x8ad5934) at sqlite3.c:117722 #5 sqlite3Parser (yyp=yyp@entry=0x8ad5908, yymajor=yymajor@entry=1, yyminor=..., pParse=pParse@entry=0x8ada460) at sqlite3.c:53224 #6 0x414e8cb4 in sqlite3RunParser (pParse=pParse@entry=0x8ada460, zSql=zSql@entry=0x8ad9f58 "SELECT DISTINCT (SELECT \"nie:url\" FROM \"nie:DataObject\" WHERE ID = \"1_u\") COLLATE TRACKER AS \"2_u\", CAST (\"urn_u_rank\" AS TEXT) AS \"3_u\", COALESCE(SparqlFormatTime ((SELECT \"nfo:fileLastModified\" FROM"..., pzErrMsg=pzErrMsg@entry=0xbfffe294) at sqlite3.c:119590 #7 0x414e92e4 in sqlite3Prepare (db=db@entry=0x87789b8, zSql=zSql@entry=0x8ad9f58 "SELECT DISTINCT (SELECT \"nie:url\" FROM \"nie:DataObject\" WHERE ID = \"1_u\") COLLATE TRACKER AS \"2_u\", CAST (\"urn_u_rank\" AS TEXT) AS \"3_u\", COALESCE(SparqlFormatTime ((SELECT \"nfo:fileLastModified\" FROM"..., nBytes=nBytes@entry=-1, saveSqlFlag=saveSqlFlag@entry=1, pReprepare=pReprepare@entry=0x0, ppStmt=ppStmt@entry=0xbfffe338, pzTail=pzTail@entry=0x0) at sqlite3.c:99779 #8 0x414e9606 in sqlite3LockAndPrepare (db=0x87789b8, zSql=0x8ad9f58 "SELECT DISTINCT (SELECT \"nie:url\" FROM \"nie:DataObject\" WHERE ID = \"1_u\") COLLATE TRACKER AS \"2_u\", CAST (\"urn_u_rank\" AS TEXT) AS \"3_u\", COALESCE(SparqlFormatTime ((SELECT \"nfo:fileLastModified\" FROM"..., nBytes=-1, saveSqlFlag=1, pOld=0x0, ppStmt=0xbfffe338, pzTail=0x0) at sqlite3.c:99871 ---Type <return> to continue, or q <return> to quit--- #9 0x4165af2f in tracker_db_interface_create_statement () from /usr/lib/tracker-0.16/libtracker-data.so.0 #10 0x41632655 in tracker_sparql_query_exec_sql_cursor () from /usr/lib/tracker-0.16/libtracker-data.so.0 #11 0x4163784a in tracker_sparql_query_execute_cursor () from /usr/lib/tracker-0.16/libtracker-data.so.0 #12 0x415f4193 in tracker_direct_connection_query_unlocked.isra.2 () from /lib/libtracker-sparql-0.16.so.0 #13 0x415f4525 in tracker_direct_connection_real_query_async_co () from /lib/libtracker-sparql-0.16.so.0 #14 0x415ea7a0 in tracker_sparql_connection_query_async () from /lib/libtracker-sparql-0.16.so.0 #15 0x415e4dcb in tracker_sparql_backend_real_query_async_co () from /lib/libtracker-sparql-0.16.so.0 #16 0x415ea7a0 in tracker_sparql_connection_query_async () from /lib/libtracker-sparql-0.16.so.0 #17 0x0812db83 in nautilus_search_engine_tracker_start () #18 0x0811ec4f in nautilus_search_provider_start () #19 0x0811efa5 in search_engine_start_real () #20 0x0811ec4f in nautilus_search_provider_start () #21 0x0811d250 in start_search () #22 0x080f3f79 in nautilus_directory_file_monitor_add () #23 0x080a63da in finish_loading_if_all_metadata_loaded () #24 0x080a6552 in metadata_for_files_in_directory_ready_callback () #25 0x0811cb36 in search_callback_invoke_and_destroy () #26 0x080f3e01 in nautilus_directory_call_when_ready () #27 0x080b2824 in load_directory () #28 0x080b29b0 in nautilus_view_load_location () #29 0x080b67fe in load_new_location () #30 0x080b7744 in create_content_view () #31 0x080baa63 in got_file_info_for_view_selection_callback () #32 0x0811e89d in search_directory_file_call_when_ready () #33 0x0810d4c1 in nautilus_file_call_when_ready () #34 0x080b8833 in begin_location_change () #35 0x080b8d93 in nautilus_window_slot_open_location_full () #36 0x080ba327 in query_editor_changed_callback () #37 0x4999d4e6 in ffi_call_SYSV () at ../src/x86/sysv.S:65 #38 0x4999d26c in ffi_call (cif=<optimized out>, cif@entry=0xbfffeb34, fn=<optimized out>, rvalue=<optimized out>, avalue=<optimized out>, avalue@entry=0xbfffea80) at ../src/x86/ffi.c:411 #39 0x499b00a1 in g_cclosure_marshal_generic (closure=0x846f540, return_gvalue=0x0, n_param_values=3, param_values=0xbfffecb0, invocation_hint=0xbfffec58, marshal_data=0x0) at gclosure.c:1454 #40 0x499af7de in g_closure_invoke (closure=0x846f540, return_value=return_value@entry=0x0, n_param_values=3, ---Type <return> to continue, or q <return> to quit--- param_values=param_values@entry=0xbfffecb0, invocation_hint=invocation_hint@entry=0xbfffec58) at gclosure.c:777 #41 0x499c256e in signal_emit_unlocked_R (node=node@entry=0x83bdd20, detail=detail@entry=0, instance=0x8326360, emission_return=emission_return@entry=0x0, instance_and_params=0xbfffecb0) at gsignal.c:3586 #42 0x499ca3c1 in g_signal_emit_valist (instance=instance@entry=0x8326360, signal_id=signal_id@entry=334, detail=detail@entry=0, var_args=0xbfffee14 "", var_args@entry=0xbfffee0c "@Zx\b\001") at gsignal.c:3330 #43 0x499ca654 in g_signal_emit (instance=0x8326360, signal_id=334, detail=0) at gsignal.c:3386 #44 0x0809dc31 in nautilus_query_editor_changed_force.constprop.3 () #45 0x0809dc68 in typing_timeout_cb () #46 0x498af262 in g_timeout_dispatch (source=source@entry=0x8519408, callback=0x809dc40 <typing_timeout_cb>, user_data=0x8326360) at gmain.c:4451 #47 0x498ae556 in g_main_dispatch (context=0x81dd0a8) at gmain.c:3066 #48 g_main_context_dispatch (context=context@entry=0x81dd0a8) at gmain.c:3642 #49 0x498ae920 in g_main_context_iterate (context=context@entry=0x81dd0a8, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3713 #50 0x498ae9e9 in g_main_context_iteration (context=0x81dd0a8, context@entry=0x0, may_block=may_block@entry=1) at gmain.c:3774 #51 0x49c067ac in g_application_run (application=0x81c50e0, argc=1, argv=0xbffff054) at gapplication.c:1635 #52 0x08067b3d in main () (gdb) list 114173 if( (pLoop->wsFlags & WHERE_ONEROW)==0 ){ 114174 if( pLoop->wsFlags & WHERE_IPK ){ 114175 pIndex = 0; 114176 nKeyCol = 0; 114177 nColumn = 1; 114178 }else if( (pIndex = pLoop->u.btree.pIndex)==0 || pIndex->bUnordered ){ 114179 return 0; 114180 }else{ 114181 nKeyCol = pIndex->nKeyCol; 114182 nColumn = pIndex->nColumn; (gdb) info register eax 0x10000 65536 ecx 0x4 4 edx 0xf 15 ebx 0x41538000 1095991296 esp 0xbfffdda0 0xbfffdda0 ebp 0x87b5b08 0x87b5b08 esi 0x0 0 edi 0x0 0 eip 0x414b5cd2 0x414b5cd2 <wherePathSatisfiesOrderBy+1346> eflags 0x10206 [ PF IF RF ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51
(In reply to sevennity from comment #15) > Delete file > home/.cache/tracker/meta.db-wal > This work for me. I tried this, but I ran into bug #1031443. And after tracker-store having 100% CPU for a minute or so, I ran into bug #1079740.
(In reply to Pablo Rodríguez from comment #17) https://www.youtube.com/watch?feature=player_detailpage&v=w3OMYdkkH9s
(In reply to sevennity from comment #18) > (In reply to Pablo Rodríguez from comment #17) > > https://www.youtube.com/watch?feature=player_detailpage&v=w3OMYdkkH9s Thanks that worked
(In reply to sevennity from comment #18) > (In reply to Pablo Rodríguez from comment #17) > > https://www.youtube.com/watch?feature=player_detailpage&v=w3OMYdkkH9s Many thanks for your help. This worked now. Your original comment was about removing a single file, but the video shows that the whole contents from the .cache/tracker/ directory were to be removed. Many thanks for your help again.
(In reply to Pablo Rodríguez from comment #20) TRACKER is ugly monster https://bugzilla.redhat.com/show_bug.cgi?id=747689 God-speed SeveN
Deleting the content of ~/.cache/tracker doesn't work for me. The only workaround I am aware of at the moment is to downgrade sqlite to 3.8.3-1.fc20 (given that the current Firefox depends on sqlite-3.8.4, I have to LD_PRELOAD the older libsqlite3.so.0.8.6 for Nautilus). Is it actually a sqlite bug, maybe? Updating to the currently pending sqlite-3.8.4.2-1.fc20 http://koji.fedoraproject.org/koji/search?terms=sqlite-3.8.4.2-1.fc20&type=build&match=glob doesn't help. The issue seems indeed to be limited to i686, can't reproduce the crash on x86_64.
Another user experienced a similar problem: i can see this error every time, when i type any char in nautilus search string. reporter: libreport-2.2.0 backtrace_rating: 4 cmdline: /usr/bin/nautilus --no-default-window crash_function: wherePathSatisfiesOrderBy executable: /usr/bin/nautilus kernel: 3.13.8-200.fc20.i686 package: nautilus-3.10.1-3.fc20 reason: nautilus killed by SIGSEGV runlevel: N 5 type: CCpp uid: 1000
> https://www.youtube.com/watch?feature=player_detailpage&v=w3OMYdkkH9s that worked, thanks!
(In reply to kemuri from comment #24) > > https://www.youtube.com/watch?feature=player_detailpage&v=w3OMYdkkH9s > that worked, thanks! It worked for me also, but only once. After I restarted the computer, the bug was still there. Could you confirm this?
If I drop -DSQLITE_ENABLE_FTS3=3 from $CFLAGS http://pkgs.fedoraproject.org/cgit/sqlite.git/tree/sqlite.spec?h=f20#n123 when building sqlite 3.8.4.2, this Nautilus crash goes away. In case this Nautilus bug is related to a possible sqlite issue, I've taken the liberty to CC the SQLite maintainer.
(In reply to Ilja Sekler from comment #26) > If I drop -DSQLITE_ENABLE_FTS3=3 from $CFLAGS > > http://pkgs.fedoraproject.org/cgit/sqlite.git/tree/sqlite.spec?h=f20#n123 > > when building sqlite 3.8.4.2, this Nautilus crash goes away. In case this > Nautilus bug is related to a possible sqlite issue, I've taken the liberty > to CC the SQLite maintainer. This works, because you'll disable, beside other things, nautilus-tracker fts extension. This is maybe not desired, not talking about other things that may break because of missing fts3 support in sqlite. But it has something to do with the sqlite update (last working version here, that means without nautilus crashing, is 3.8.3.1), though I still cannot say if this is a bug on the sqlite side or rather a bad use of the api in nautilus and/or tracker (I do not know enough about the code involved here to really track down the issue). There obviously were some changes between 3.8.3.x and 3.8.4.x in sqlite that nautilus (maybe tracker, too) dislikes. A simple recompilation of nautilus/tracker against newer sqlite packages does not seem to help here. Any profound guesses which code really is to blame?
Hi, sqlite mainainer here. I'm not sure I will be of much help - I went trough the sqlite code in functions mentioned by above traceback, and could not find any obvious errors. From the sqlite changelog (http://www.sqlite.org/changes.html) there was some changes in handling WHERE and DISTINCT clauses. Is there any possibility that the tracker relies on the previous behaviour? Again, I'm really as much in the dark here as you, so take my points only as guesses.
(In reply to Jan Staněk from comment #28) > [...] I went trough the sqlite code in functions mentioned by above traceback, > and could not find any obvious errors. > > From the sqlite changelog (http://www.sqlite.org/changes.html) there was > some changes in handling WHERE and DISTINCT clauses. Is there any > possibility that the tracker relies on the previous behaviour? Due to the crash being restricted to i686 while x86_64 remains perfectly fine, could it be in fact a compiler bug?
Folks, while we pontificate, hundreds of people are hitting this crash, according to FAF - https://retrace.fedoraproject.org/faf/problems/1616779/ . So far it's been hit 34,105 times(!) If we don't know what the bug is and how to fix it right now, what we need to do is downgrade sqlite as an 'update'. That involves an epoch bump and epoch bumps are Bad and Evil and yadda yadda, but this is a situation where they'd be justified. So Jan, can you please as a matter of urgency do an 'upgrade' to the last working sqlite (which appears to be 3.8.3.1) with an epoch bump, and send that out? If there's anything you're unsure of in that process, mclasen or I could help. We then have time to fix the crash at our leisure and re-issue the update (if it's appropriate at all) only when we're sure it's good.
Oh, as a hedge against this being a compiler issue, please only do the downgrade for F20 for now (not Rawhide), and submit the update only to updates-testing. If the downgraded-but-rebuilt sqlite still triggers the bug, we'll know it's some kind of compile-time issue, and we can just withdraw the update and then we won't be committed to the epoch bump.
(In reply to Adam Williamson from comment #30) > Folks, while we pontificate, hundreds of people are hitting this crash, > according to FAF - https://retrace.fedoraproject.org/faf/problems/1616779/ . > So far it's been hit 34,105 times(!) > > If we don't know what the bug is and how to fix it right now, what we need > to do is downgrade sqlite as an 'update'. That involves an epoch bump and > epoch bumps are Bad and Evil and yadda yadda, but this is a situation where > they'd be justified. In case we're sure downgrading sqlite is worth the result, we can go that way, but are we actually sure enough that the older build makes things better? Since there are so many people in the CC, could someone, please, test the rebuilt scratch-build of 3.8.4.2-2 (http://koji.fedoraproject.org/koji/taskinfo?taskID=6765432) and then try to downgrade to the scratch-build version 3.8.3-1 (http://koji.fedoraproject.org/koji/taskinfo?taskID=6765463) and confirm that 3.8.4.2-2 is broken and 3.8.3-1 fixes the crash? Not necessary to mention, that if anybody came with a stabil reproducer, it would be really great.
"In case we're sure downgrading sqlite is worth the result, we can go that way, but are we actually sure enough that the older build makes things better?" That's why I suggested sending it to updates-testing...but of course, trying your scratch build would be good too.
Is anyone testing the scrath-builds or should I still try the epoch-bump? I do not have GNOME installed, so I can't test it myself.
I can try to find time to see if I can reproduce this in a 32-bit VM install tomorrow...
I'm able to reproduce with my i386 VM, it works with: sqlite-3.8.3-1.fc20.i686 and it crashes with: sqlite-3.8.4-1.fc20.i686 I also found that firefox and xulrunner already requrie `sqlite >= 3.8.4`, which is a build-time-generated requirement, so these packages would have to be enhanced to take epoch into account as well, but it is not that important right now. However, I'd like to try to look at the code tomorrow and try my luck to find a fix instead of bumping epoch. If I don't succeed, me or Jan will do the downgrade+epoch bump, probably tomorrow..
Thanks for testing and taking care of this!
Created attachment 889642 [details] Patch that reverts part of the upstream's commit dca1945aeb3fb005 I seems that this issue was introduced by upstream's commit dca1945aeb3fb005263f9be00ee8e72b966ae303 [2] and when applying the attached patch (which reverts part of the commit above), it works fine for me, so we'll use it as a temporary fix. Unfortunately, I found that I don't have commit rights for sqlite any more, so I asked Vit Ondruch to build it, but responsibility is still on my side. Thank you, Vita! Just for recap, the problem we see in nautilus is that sqlite crashes during running the following select query (grabbed from GDB, so some values are missing and it is usable in sqlite console just like this): SELECT DISTINCT (SELECT "nie:url" FROM "nie:DataObject" WHERE ID = "1_u") COLLATE TRACKER AS "2_u", CAST ("urn_u_rank" AS TEXT) AS "3_u", COALESCE(SparqlFormatTime ( (SELECT "nfo:fileLastModified" FROM "nfo:FileDataObject" WHERE ID = "1_u")), SparqlFormatTime ( (SELECT "nie:contentLastModified" FROM "nie:InformationElement" WHERE ID = "1_u"))) AS "4_u", COALESCE(SparqlFormatTime ( (SELECT "nfo:fileLastAccessed" FROM "nfo:FileDataObject" WHERE ID = "1_u")), SparqlFormatTime ( (SELECT "nie:contentAccessed" FROM "nie:InformationElement" WHERE ID = "1_u"))) AS "5_u" FROM (SELECT "nfo:FileDataObject1"."ID" AS "1_u", 1, "fts3"."docid" AS "ID", tracker_rank(matchinfo("fts3"."fts", 'cl'),fts_column_weights()) AS "urn_u_rank" FROM "nfo:FileDataObject" AS "nfo:FileDataObject1", "nie:DataObject" AS "nie:DataObject2", "fts" AS "fts3" WHERE "nfo:FileDataObject1"."ID" = "nie:DataObject2"."ID" AND "nie:DataObject2"."ID" = "fts3"."docid" AND "nie:DataObject2"."tracker:available" = ? AND "fts3"."fts" MATCH '"status*"' AND (SparqlUriIsDescendant(? COLLATE TRACKER, (SELECT "nie:url" FROM "nie:DataObject" WHERE ID = "1_u") COLLATE TRACKER) AND (SparqlLowerCase ( (SELECT "nfo:fileName" FROM "nfo:FileDataObject" WHERE ID = "1_u") COLLATE TRACKER) GLOB ?))) ORDER BY "urn_u_rank" DESC
Fix commited: http://pkgs.fedoraproject.org/cgit/sqlite.git/commit/?h=f20&id=50f9f44bea599820760f97af7dbbf90bd184d58b Builds are already on the way; until they're ready, this is a testing scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=6777866
sqlite-3.8.4.2-3.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/sqlite-3.8.4.2-3.fc20
The SQLite team is unable to reproduce the problem. Can you please send the schema that corresponds to the large query in comment 38. The schema can be obtained using: sqlite3 $database .schema Thanks.
Created attachment 889745 [details] Schema of the tracker DB (In reply to Richard Hipp from comment #41) > The SQLite team is unable to reproduce the problem. Can you please send the > schema that corresponds to the large query in comment 38. The schema can be > obtained using: > > sqlite3 $database .schema Sure, scheme retrieved by `sqlite3 ~/.cache/tracker/meta.db .schema` is attached. It's already sent by e-mail, but attaching here as well for anybody else interested.
Tnx for the schema. We can recreate the problem now. The SQLite trouble ticket can be seen here: http://www.sqlite.org/src/tktview/388d01d4bb8f9a
can folks who were hitting this crash please test the sqlite update and provide positive feedback in Bodhi if it works? that'd be much appreciated. "yum --enablerepo=updates-testing update sqlite" will install the updated sqlite once it makes it to the updates-testing repository (it isn't there yet, if you want to get a head start, you can grab the updated package from http://koji.fedoraproject.org/koji/buildinfo?buildID=513105 ).
The SQLite ticket for this issue (http://www.sqlite.org/src/tktview/388d01d4bb8f9a8b1c798d9453819914134ab603) has now been closed. The official fix can be seen at http://www.sqlite.org/src/info/171138122690f Note that the fix checked into the RedHat git repository (http://pkgs.fedoraproject.org/cgit/sqlite.git/commit/?h=f20&id=50f9f44bea599820760f97af7dbbf90bd184d58b) prevents the problem from occurring in the specific query used by Nautilus by disabling certain query optimizations. But that patch does not fix the underlying error, which could still be hit using a different query. You may want to consider replacing the RedHat-git fix with the official fix checked into the canonical SQLite Fossil repository, shown in the second link of this message.
do i need to get another operating system?
i don't have an email account with gmail anymore so any information you may have sent I dids not get all I need is a yes or no do I need to get another operating system?
well I see I'm notb getting an answerso i'll wipe my drive clean and that should just about fix the bug problem on fedora 20 HAVE A F##### NICE DAY
(In reply to Albert from comment #46) > do i need to get another operating system? Albert, I guess this is a question you should answer yourself. The bug has been fixed (as explained in previous comments). If the bug was a reason to use another OS, I cannot see why you should want to change your OS. (In reply to Albert from comment #47) > i don't have an email account with gmail anymore so any information you may > have sent I dids not get all I need is a yes or no do I need to get another > operating system? See my reply above. Your issue with your GMail account seems not to be related with this bug. If it actually is, please explain why. (In reply to Albert from comment #48) > well I see I'm notb getting an answerso i'll wipe my drive clean and that > should just about fix the bug problem on fedora 20 HAVE A F##### NICE DAY If you expect to have a reply in less than ten minutes from your original question, I'm afraid your expectations are simply unrealistic. Your question was posted on a Saturday afternoon, so it would be replied next Monday. If you want to solve the problem, type as root (as written in comment #44): yum --enablerepo=updates-testing update sqlite If you want to remove Fedora 20 from your hard disk, please do as it fits you best. As a general matter, people here are willing to help. One can ask for help, but one cannot demand help. Helping people aren’t servants. And one last question: if you get upset for not having your question inmediately replied, keep it calm. If you are in such a hurry, avoid wasting time wishing a *fabulous* nice day.
I've tried repeatedly to find an answer for this bug which won't even let me go to the folder mention in the youtube video so I ask anybody else got any other great ideas?I didn't make this bug nothing I've done so far has did any good each time I try one of these great suggestions I feel like i'm shooting myself in the foot.They say the bug is fixed each time I log onto my computer it ask me for a password and when i type the password in it says incorrect password if Itry going to any file search it does the same thing I must really be stupid or blind maybe both,here's your sign.So it seems all I can do is scrap the system and start all over cause it appears to me that the bug isn't fixed and it is not about to be cause nobody seems to know what caused it in the first place but when I do get it right again I will not do any more updateing because it's unreliable if had not updated my system I wouldn't be in this fix now
Comment on attachment 873801 [details] File: cgroup IT DOES NOT WORK
Albert: Please bring up your issue in http://forums.fedoraforum.org/ instead. Your problem seems rather unrelated to the problem discussed in this bug report. Thanks for your understanding.
Honza: should we switch to the upstream fix for this, as suggested in c#45?
(In reply to Adam Williamson from comment #53) > Honza: should we switch to the upstream fix for this, as suggested in c#45? I guess we should, but in order to have a working build in stable repo asap, I'd recommend to let the current build be marked stable by bodhi and include the upstream fix together with the next update in couple of days.
Sure, sounds fine. The update is being pushed stable for F20 right now.
sqlite-3.8.4.2-3.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
sqlite-3.8.4.3-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/sqlite-3.8.4.3-1.fc20
As mentioned in above comment, sqlite version with upstream patch to this problem is being pushed to testing.
sqlite-3.8.4.3-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.