[tracker-miners/wip/carlosg/coverity-fixes: 28/28] libtracker-miner: Plug possible leak on error paths




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]