Created attachment 585 
Backtrace for Xfce4-Appfinder

Well it seems the same bug, which I experience.
Now there are two place in the source, where I simply fail to grok the logic and look more like typos:
in function build_desktop_paths it goes at the end like this:
    for (n = 0; n < napplnk; ++i, ++n)
    {
        desktop_entries_paths[i] = applnk[n];
    }
    g_free (applnk);
    
    desktop_path_number = n;
so here n is the number of entries in applink and not the end of the desktop_entries_paths (so it is in some random place in it). Just changing it to i makes the segfaults disappear for me.
But this is only the half of the story, this value is used in createDesktopCache, also at the end of it - n is desktop_path_number-1:
                else if (g_file_test(fullpath, G_FILE_TEST_IS_DIR))
                {
                    desktop_entries_paths[n] = fullpath;
                    desktop_entries_paths[n] = NULL;
                }
            }
            g_dir_close(dir);
        }
        i++;
which I really could not grasp, since the double assignment is useless, even if it is typo aka n-1, n or sth like this, it does not make sense to me, as it should add dirs to be scanned recursively and desktop_entries_paths is fixed size array - so changing only the last entry in order to add new dir to be scanned, would not do in certain situations - /usr/share/applications having >1 subdirectories, as simply the last found dir will overwrite this entry in the array.
I have made a patch to use GPtrArray instead of fixed array for desktop_entries_paths and it seems to work fine here (also adding desktop entries from /usr/share/applications/screensavers and such), but I have never written anything glib/gtk related, so it should be taken with grasp of salt :)

Created attachment 822 
g_ptr_array.patch

patch to use GPtrArray instead of fixed array

I can confirm this still exists in svn trunk, and this pacth solves it

Comment 5 Jasper Huijsmans 2006-12-09 11:40:35 CET

Gergan, thank you very much for that patch. It makes a lot of sense to me, so I have committed it to SVN with revision 24071.