[tracker-miners/wip/carlosg/coverity-fixes: 28/28] libtracker-miner: Plug possible leak on error paths
- From: Carlos Garnacho <carlosg src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [tracker-miners/wip/carlosg/coverity-fixes: 28/28] libtracker-miner: Plug possible leak on error paths
- Date: Sun, 24 Oct 2021 11:33:40 +0000 (UTC)
commit 846359dda91b9047861cd15d216475d361b2032e
Author: Carlos Garnacho <carlosg gnome org>
Date: Sun Oct 24 13:04:07 2021 +0200
libtracker-miner: Plug possible leak on error paths
Coverity seems really confused about item_add_or_update(), thinking
it can unref the given file argument, while it just holds a temporary
extra ref.
However that ref (and the uri string) might leak if fetching a
GFileInfo failed. Avoid the ref altogether, since this is not subject
to reentrancy issues that might make the reference necessary. And
shuffle the uri string creation so it's not leaked there.
CID: #365678
src/libtracker-miner/tracker-miner-fs.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
---
diff --git a/src/libtracker-miner/tracker-miner-fs.c b/src/libtracker-miner/tracker-miner-fs.c
index f496f45af..a49e8dbe2 100644
--- a/src/libtracker-miner/tracker-miner-fs.c
+++ b/src/libtracker-miner/tracker-miner-fs.c
@@ -1114,10 +1114,6 @@ item_add_or_update (TrackerMinerFS *fs,
{
gchar *uri;
- g_object_ref (file);
-
- uri = g_file_get_uri (file);
-
if (!info) {
info = g_file_query_info (file,
fs->priv->file_attributes,
@@ -1128,6 +1124,8 @@ item_add_or_update (TrackerMinerFS *fs,
if (!info)
return TRUE;
+ uri = g_file_get_uri (file);
+
if (!attributes_update) {
TRACKER_NOTE (MINER_FS_EVENTS, g_message ("Processing file '%s'...", uri));
TRACKER_MINER_FS_GET_CLASS (fs)->process_file (fs, file, info,
@@ -1142,7 +1140,6 @@ item_add_or_update (TrackerMinerFS *fs,
fs->priv->total_files_processed++;
g_free (uri);
- g_object_unref (file);
return TRUE;
}
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]