Created attachment 223620 [details] [review]
ephy-history-service: fix a few leaks

If there is an error processing the statement, then unref it before
returning.

Created attachment 223621 [details] [review]
ephy-history-service: remove some dangerous g_object_unref() calls

If there is an error building a statement, the returned value is
always NULL. Calling g_object_unref() on them will lead to trouble.

Review of attachment 223620 [details] [review]:

::: lib/history/ephy-history-service-hosts-table.c
@@ +78,3 @@
     g_error ("Could not insert host into hosts table: %s", error->message);
     g_error_free (error);
+    g_object_unref (statement);

There seems to be a another place in this method, the next return, that should get the same treatment? And perhaps the previous one, depending on whether the statement can be NULL if error is not NULL.

@@ +120,3 @@
     g_error ("Could not modify host in hosts table: %s", error->message);
     g_error_free (error);
+    g_object_unref (statement);

Same.

::: lib/history/ephy-history-service-urls-table.c
@@ +152,3 @@
     g_error ("Could not insert URL into urls table: %s", error->message);
     g_error_free (error);
+    g_object_unref (statement);

Same.

@@ +195,3 @@
     g_error ("Could not modify URL in urls table: %s", error->message);
     g_error_free (error);
+    g_object_unref (statement);

And same.

::: lib/history/ephy-history-service-visits-table.c
@@ +73,3 @@
     g_error ("Could not build visits table addition statement: %s", error->message);
     g_error_free (error);
+    g_object_unref (statement);

And same (basically all 'same's are about whether statement can be non-NULL if the error is set on creation).

Review of attachment 223621 [details] [review]:

OK, whatever, this kinda asks my previous questions.

Attachment 223620 [details] pushed as c514bd1 - ephy-history-service: fix a few leaks
Attachment 223621 [details] pushed as dddc036 - ephy-history-service: remove some dangerous g_object_unref() calls