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 785723 - Search providers handling can make Nautilus crash
Search providers handling can make Nautilus crash
Status: RESOLVED OBSOLETE
Product: nautilus
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-08-02 10:07 UTC by Alexandru Pandelea
Modified: 2021-06-18 15:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
search-engine: fix search providers handling (1.83 KB, patch)
2017-08-02 10:08 UTC, Alexandru Pandelea
none Details | Review
search-engine: fix search providers handling (5.64 KB, patch)
2017-08-08 13:56 UTC, Alexandru Pandelea
none Details | Review
search-engine: fix search providers handling (23.72 KB, patch)
2017-08-08 17:22 UTC, Alexandru Pandelea
none Details | Review
search-engine: fix search providers handling (23.76 KB, patch)
2017-08-16 16:54 UTC, Alexandru Pandelea
none Details | Review
search-engine: fix search providers handling (24.63 KB, patch)
2017-08-17 10:59 UTC, Alexandru Pandelea
none Details | Review
search-engine: fix search providers handling (24.64 KB, patch)
2017-08-17 19:28 UTC, Alexandru Pandelea
accepted-commit_now Details | Review

Description Alexandru Pandelea 2017-08-02 10:07:39 UTC
See patch.
Comment 1 Alexandru Pandelea 2017-08-02 10:08:21 UTC
Created attachment 356770 [details] [review]
search-engine: fix search providers handling

When starting the search providers, some provider might finish
before all providers are started, so a wrong value of providers_running
will be used, making Nautilus crash.

To fix this set the value of providers_running right before starting
the providers, so a correct value of it will be used.
Comment 2 Carlos Soriano 2017-08-07 10:30:36 UTC
Review of attachment 356770 [details] [review]:

::: src/nautilus-search-engine.c
@@ +92,3 @@
+        priv->providers_running++;
+    }
+

maybe you can just move this before every provider start instead of doing the sum of all of them at once?
Comment 3 Alexandru Pandelea 2017-08-08 13:56:30 UTC
Created attachment 357194 [details] [review]
search-engine: fix search providers handling

When starting the search providers, some provider might finish
before all providers are started, so a wrong value of providers_running
will be used, making Nautilus crash.

To fix this, keep a queue of the started providers and whenever the
value of the finised/running providers is needed, check the status of
each provider.
Comment 4 Carlos Soriano 2017-08-08 14:06:57 UTC
Review of attachment 357194 [details] [review]:

Cool! Just some nitpicks

::: src/nautilus-search-engine.c
@@ +40,2 @@
     guint providers_error;
+    GQueue *providers_started;

This should probably be just "providers".

@@ +88,3 @@
+    g_queue_clear (priv->providers_started);
+
+    g_queue_push_head (priv->providers_started, priv->tracker);

this would need to change, and not have a pointer to a provider we don't use. You can just create them on demand, right?

@@ +125,3 @@
+    for (l = g_queue_peek_head_link (priv->providers_started); l != NULL; l = l->next)
+    {
+        all_providers_finished &= (!nautilus_search_provider_is_running (NAUTILUS_SEARCH_PROVIDER (l->data)));

It's usually better to use positive questions when possible. Can we have one API for search_provider_finished?
Comment 5 Alexandru Pandelea 2017-08-08 17:22:39 UTC
Created attachment 357212 [details] [review]
search-engine: fix search providers handling

When starting the search providers, some provider might finish
before all providers are started, so a wrong value of providers_running
will be used, making Nautilus crash.

To fix this, keep a queue of the started providers and whenever the
value of the finised/running providers is needed, check the status of
each provider.
Comment 6 Carlos Soriano 2017-08-15 18:43:02 UTC
Review of attachment 357212 [details] [review]:

Looking good

::: src/nautilus-search-engine.c
@@ +73,2 @@
 static void
+nautilus_search_engine_clear_providers_queue (NautilusSearchEngine *engine)

no nautilus prefix for non public API

@@ +96,3 @@
+    priv = nautilus_search_engine_get_instance_private (engine);
+
+    }

either use always nautilus_directory_unref/ref or g_object_* functions. I think we agreed to just use g_object_* so you can change the next one.

@@ +111,3 @@
 
+    g_object_ref (query);
+    g_clear_object (&priv->query);

could the query be the same (and therefore this order of refs/unrefs)? If so, is better if you add a comment, if not, ignore this comment.

@@ +450,2 @@
 static void
+nautilus_search_engine_set_property (GObject      *object,

for each property we usually put public API for set/get.
Comment 7 Alexandru Pandelea 2017-08-16 16:54:51 UTC
Created attachment 357741 [details] [review]
search-engine: fix search providers handling

When starting the search providers, some provider might finish
before all providers are started, so a wrong value of providers_running
will be used, making Nautilus crash.

To fix this, keep a queue of the started providers and whenever the
value of the finised/running providers is needed, check the status of
each provider.
Comment 8 Alexandru Pandelea 2017-08-16 16:58:48 UTC
> @@ +450,2 @@
>  static void
> +nautilus_search_engine_set_property (GObject      *object,
> 
> for each property we usually put public API for set/get.

The running property is handled internally and it shouldn't be settable from outside right?
Comment 9 Alexandru Pandelea 2017-08-16 17:10:24 UTC
Attachment 357741 [details] pushed as 37693c4 - search-engine: fix search providers handling
Comment 10 Alexandru Pandelea 2017-08-17 10:44:16 UTC
The patch was pushed by accident
Comment 11 Alexandru Pandelea 2017-08-17 10:59:20 UTC
Created attachment 357798 [details] [review]
search-engine: fix search providers handling

When starting the search providers, some provider might finish
before all providers are started, so a wrong value of providers_running
will be used, making Nautilus crash.

To fix this, keep a queue of the started providers and whenever the
value of the finised/running providers is needed, check the status of
each provider.
Comment 12 Carlos Soriano 2017-08-17 11:37:33 UTC
Review of attachment 357798 [details] [review]:

Looks mostly good! Just a few nitpicks, and I would like Ernestas to give a quick look at it.

::: src/nautilus-search-engine-tracker.c
@@ +496,3 @@
+}
+
+

extra line

::: src/nautilus-search-engine.c
@@ +131,3 @@
     priv = nautilus_search_engine_get_instance_private (engine);
 
+    /* first ref the new query and then clear the previous

Capitalize first char.

::: src/nautilus-search-provider.c
@@ +149,3 @@
+{
+    g_return_val_if_fail (NAUTILUS_IS_SEARCH_PROVIDER (provider), FALSE);
+    g_return_val_if_fail (NAUTILUS_SEARCH_PROVIDER_GET_IFACE (provider)->is_finished, FALSE);

can this ever happen? If so, does a default FALSE make sense? Couldn't it be dangerous to never finish?
Comment 13 Ernestas Kulik 2017-08-17 12:21:34 UTC
Review of attachment 357798 [details] [review]:

I don’t see anything wrong, really, just some nitpicks, too.

::: src/nautilus-search-engine-model.c
@@ +291,3 @@
+}
+
+

Extra line.

::: src/nautilus-search-engine.c
@@ +100,3 @@
+    priv = nautilus_search_engine_get_instance_private (engine);
+
+    for (l = g_queue_peek_head_link (priv->providers); l != NULL; l = l->next)

Why not just pop here if you’re clearing it afterwards?

@@ +117,3 @@
+    priv = nautilus_search_engine_get_instance_private (engine);
+
+    g_clear_object (&priv->directory);

No reason to clear if we’re resetting it right after, but it’s fine.

@@ +136,3 @@
+    g_object_ref (query);
+    g_clear_object (&priv->query);
+    priv->query = query;

This is a bit messy. I think the comment offsets the cleverness of the approach.

@@ +161,3 @@
+    g_queue_push_head (priv->providers, simple);
+
+    if (priv->directory)

!= NULL

::: src/nautilus-search-engine.h
@@ +45,3 @@
+void nautilus_search_engine_set_recursive        (NautilusSearchEngine *engine,
+                                                  gboolean              recursive);
+gboolean nautilus_search_engine_get_recursive    (NautilusSearchEngine *engine);

Should all of these be grouped? Also, the function names aren’t aligned.

::: src/nautilus-search-provider.c
@@ +149,3 @@
+{
+    g_return_val_if_fail (NAUTILUS_IS_SEARCH_PROVIDER (provider), FALSE);
+    g_return_val_if_fail (NAUTILUS_SEARCH_PROVIDER_GET_IFACE (provider)->is_finished, FALSE);

Gah, this is hairy. Yeah, defaulting to TRUE would probably be better. It’s better than to bring everything down if someone forgets to assign a pointer in the vtable.
Comment 14 Alexandru Pandelea 2017-08-17 19:28:39 UTC
Created attachment 357833 [details] [review]
search-engine: fix search providers handling

When starting the search providers, some provider might finish
before all providers are started, so a wrong value of providers_running
will be used, making Nautilus crash.

To fix this, keep a queue of the started providers and whenever the
value of the finised/running providers is needed, check the status of
each provider.
Comment 15 Carlos Soriano 2017-08-23 13:04:28 UTC
Review of attachment 357833 [details] [review]:

Looks good now!
Comment 16 André Klapper 2021-06-18 15:53:41 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version of Files (nautilus), then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/nautilus/-/issues/

Thank you for your understanding and your help.