After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 692041 - Search provider does not show any results
Search provider does not show any results
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: File Search Interface
3.6.x
Other Linux
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-01-18 22:46 UTC by drago01
Modified: 2013-09-20 16:26 UTC
See Also:
GNOME target: 3.10
GNOME version: ---


Attachments
make the skeleton signal handler functions return TRUE (3.95 KB, patch)
2013-09-20 14:49 UTC, David King
committed Details | Review

Description drago01 2013-01-18 22:46:29 UTC
I upgraded one system from F17 to F18 and noticed that the search provider does not show any results in the shell.

I have started it using 
G_MESSAGES_DEBUG=all NAUTILUS_SEARCH_PROVIDER_PERSIST=1 /usr/libexec/nautilus-shell-search-provider --g-fatal-warnings

and attached gdb to it and got this backtrace:

Program received signal SIGTRAP, Trace/breakpoint trap.
g_logv (log_domain=0x7fc5de11d3a4 "GLib-GObject", log_level=
    G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=
    0x7fff62132488) at gmessages.c:974
974		  g_private_set (&g_log_depth, GUINT_TO_POINTER (depth));
(gdb) bt
  • #0 g_logv
    at gmessages.c line 974
  • #1 g_log
    at gmessages.c line 1003
  • #2 pending_search_free
    at nautilus-shell-search-provider.c line 143
  • #3 pending_search_finish
    at nautilus-shell-search-provider.c line 161
  • #4 search_finished_cb
    at nautilus-shell-search-provider.c line 240
  • #5 g_closure_invoke
    at gclosure.c line 777
  • #6 signal_emit_unlocked_R
    at gsignal.c line 3551
  • #7 g_signal_emit_valist
  • #8 g_signal_emit
    at gsignal.c line 3356
  • #9 nautilus_search_provider_finished
    at nautilus-search-provider.c line 145
  • #10 check_providers_status
    at nautilus-search-engine.c line 193
  • #11 g_closure_invoke
    at gclosure.c line 777
  • #12 signal_emit_unlocked_R
    at gsignal.c line 3551
  • #13 g_signal_emit_valist
    at gsignal.c line 3300
  • #14 g_signal_emit
    at gsignal.c line 3356
  • #15 nautilus_search_provider_finished
    at nautilus-search-provider.c line 145
  • #16 search_finished
    at nautilus-search-engine-tracker.c line 108
  • #17 cursor_callback
    at nautilus-search-engine-tracker.c line 151
  • #18 g_simple_async_result_complete
    at gsimpleasyncresult.c line 775
  • #19 complete_in_idle_cb_for_thread
    at gsimpleasyncresult.c line 843
  • #20 g_main_dispatch
    at gmain.c line 2715
  • #21 g_main_context_dispatch
    at gmain.c line 3219
  • #22 g_main_context_iterate
    at gmain.c line 3290
  • #23 g_main_context_iteration
    at gmain.c line 3351
  • #24 g_application_run
    at gapplication.c line 1624
  • #25 main
    at nautilus-shell-search-provider.c line 853


The state seems to be showhow messed up as other calls to the interface seem to result into "Method GetSubsearchResultSet is not implemented on interface org.gnome.Shell.SearchProvider"

A second system with nearly identical setup (but different hardware) seems to work fine
Comment 1 drago01 2013-01-18 23:03:12 UTC
I am not getting the 

(nautilus-shell-search-provider:7579): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed 

So whatever causes this seems to trigger this bug.
Comment 2 drago01 2013-02-01 18:39:38 UTC
So I did some more debugging I found out that:

1) it works when running inside gdb
2) it works when tracker is disabled (--disable-tracker)

So I looked at the tracker search engine implementation and could not find anything obvious either by trial and error I found that the check in check_pending_hits() seems to be causing it.

This patch:

diff --git a/libnautilus-private/nautilus-search-engine-tracker.c b/libnautilus-private/nautilus-search-engine-tracker.c
index b791620..08b55d5 100644
--- a/libnautilus-private/nautilus-search-engine-tracker.c
+++ b/libnautilus-private/nautilus-search-engine-tracker.c
@@ -75,12 +75,12 @@ check_pending_hits (NautilusSearchEngineTracker *tracker,
 {
        GList *hits = NULL;
        NautilusSearchHit *hit;
-
+#if 0
        if (!force_send &&
            g_queue_get_length (tracker->details->hits_pending) < BATCH_SIZE) {
                return;
        }
-
+#endif
        while ((hit = g_queue_pop_head (tracker->details->hits_pending))) {
                hits = g_list_prepend (hits, hit);
        }


makes it work again .. I do not know *why* though.
Comment 3 drago01 2013-02-01 19:30:20 UTC
OK this has nothing to do with this patch. For some reason the one built by jhbuild (9e53ab4d077846baa1284e18a37c94360df3bec8) works now (without any patches) while the one shipped by fedora does not.

So seems like something in my jhbuild environment changed that made it work.
Comment 4 taniglu.budikov 2013-03-16 10:29:55 UTC
Same problems under ARCHLINUX x86_64.

Nautilus 3.6.3
tracker/tracker-sparql 0.14.4
dbus 1.6.8
gnome-shell 3.6.3.1

when searching under gnome shell; logs are filled with message :

"Method GetSubsearchResultSet is not implemented on interface
org.gnome.Shell.SearchProvider".

Using drago01 method to find what is wrong; got the same results :

core dump for nautilus-search-provider
Comment 5 David King 2013-09-17 19:36:22 UTC
I was investigating this today, with Nautilus 3.9.91 in Fedora 20, and for the system-installed version I get the same gdbus "method not implemented" error on every search query. The version I have built in jhbuild works fine for every search query with the same method call:

gdbus call --session --dest org.gnome.Nautilus.SearchProvider --object-path /org/gnome/Nautilus/SearchProvider --method org.gnome.Shell.SearchProvider2.GetInitialResultSet "['foo']"

The reported error comes from the implementation generated by gdbus-codegen, which (when it emits the error) calls g_dbus_method_invocation_return_error(), which in turn (as with other g_dbus_method_invocation functions) unrefs the GDBusMethodInvocation. Stepping through with gdb and watching the refcount of the invocation object, in the error case it is finalized before search_finished_cb() is called, which leads to the critical warning when calling g_clear_object() on the already-finalized invocation, and no search results. The jhbuild version works fine, and the invocation object is finalized at the expected point.
Comment 6 Matthias Clasen 2013-09-19 18:53:12 UTC
a patch would be greatly appreciated
Comment 7 Pierre-Yves Luyten 2013-09-20 08:06:52 UTC
curious, since commit a4b7dba3aeb6c6aa3e40896ad4d61f8c201fd299 a ref is kept on the GDBusMethodInvocation
Comment 8 Pierre-Yves Luyten 2013-09-20 08:17:32 UTC
There was some commits on GDBusMethodInvocation on glib side on 2013-06, betweeb 2.37.2 and 2.37.3

F20 depends on glib 2.35.
http://pkgs.fedoraproject.org/cgit/nautilus.git/tree/nautilus.spec?h=f20
Comment 9 David King 2013-09-20 14:49:25 UTC
Created attachment 255406 [details] [review]
make the skeleton signal handler functions return TRUE

As Matthias Clasen noticed, the signal handlers for the gdbus-codegen skeleton for the shell search provider have the wrong signature, and should return TRUE to indicate that the signal has been handled. Otherwise, it is down to chance if the method is handled or if a method-not-implemented error is emitted. It seems that the GCC option -fstack-protector-strong causes the default return value to be interpreted as FALSE, so this might explain why the problem was only noticed by a wide variety of users recently.
    
The bug manifests as Nautilus not returning any search results when using the gnome-shell activities overview search.
Comment 10 Matthias Clasen 2013-09-20 15:12:31 UTC
Review of attachment 255406 [details] [review]:

Thanks, looks correct. Can you ask for a freeze break ?
Comment 11 David King 2013-09-20 15:38:39 UTC
(In reply to comment #10)
> Thanks, looks correct. Can you ask for a freeze break ?

Sure, I will do that now. I tested a build in Koji for Fedora 20, and the patch fixes the bug for me:

http://koji.fedoraproject.org/koji/taskinfo?taskID=5961376
Comment 12 David King 2013-09-20 16:26:25 UTC
Comment on attachment 255406 [details] [review]
make the skeleton signal handler functions return TRUE

Pushed with release-team approval as commit 2e67887344aa9e347d30d0b2c69fb8c84c23b9da.