GNOME Bugzilla – Bug 744611
Crash in recent manager when saving to non-writable location
Last modified: 2015-10-17 18:30:07 UTC
When saving a file to a non-writable location, say / for example, gedit crashes in build_recent_info.
+ Trace 234656
$1 = (GtkRecentInfo *) 0x7fffc8608ed0 (gdb) print info->uri $2 = (gchar *) 0x7fffc8608f40 "file:///Ungespeichertes%20Dokument%201" (gdb) print groups $3 = (gchar **) 0x0 (gdb) print groups_len $4 = 140737294360117 gtk_recent_manager_get_items is iterating over all items found in the according GBookmarks->items and then build_recent_info is looking up the item in GBookmarks->items_by_uri when calling g_bookmark_file_get_groups. The crash indicates that items contains an element that is not found in items_by_uri. I couldn't find any place where only items was modified without changing items_by_uri accordingly, so I'm guessing it might be a threading issue where for example an item is added to items but not yet added to items_by_uri in one thread while another thread tries to do a lookup. The crash itself could be fixed by checking g_bookmark_file_get_groups and g_bookmark_file_get_applications for NULL in build_recent_info, but there has to be some underlying issue if those are NULL to begin with.
hi, yeah, threading issue, i'll try fixing that ASAP. thanks for your report
same crash on gedit 3.16.2
PS. I'm not saving in a non-writable location and only in my home directory. But it was the same exact trace so I know it is the same bug.
Created attachment 310275 [details] [review] OpenDocumentSelector: Fetch recent list in an idle We get some crashes due to the fetching of the recent list in a thread like other lists of the store. GtkRecentManager can't be use in a thread other than the main one.
Created attachment 310283 [details] [review] OpenDocumentSelector: Fetch recent list in an idle We get some crashes due to the fetching of the recent list in a thread like other lists of the store. GtkRecentManager can't be use in a thread other than the main one.
Attachment 310283 [details] pushed as 3f9f632 - OpenDocumentSelector: Fetch recent list in an idle
I think this fix may be causing performance issues when opening files with gedit if ~/.local/share/recently-used.xbel is huge enough.
hi, the fact is that the recent list is fetched in the UI process now ( compared to a thread before ) because this is the way the GtkRecentManager is supposed to be used. Add to this the fact that i can only test this with an SSD device ( so very fast timing ) Can you provide us with stats on your .xbel file ? ( number of entries...) Something like seems to work: grep "<bookmark href" ~/.local/share/recently-used.xbel|wc -l grep "<bookmark:group>gedit" ~/.local/share/recently-used.xbel|wc -l Notice that if you can build Gedit, you can also get timings for each fetched list by activating the inlined debug code : https://git.gnome.org/browse/gedit/tree/gedit/gedit-open-document-selector-helper.h#n51 ( Put 1 instead of 0 to activate this, then rebuild )
grep "<bookmark href" ~/.local/share/recently-used.xbel|wc -l 165 grep "<bookmark:group>gedit" ~/.local/share/recently-used.xbel|wc -l 99 Rebuilding now. will post soon.
as a comparaison and with a SSD device, my xbel has 885 entries ( 22 for gedit ) and the list is build in time:0.018676 s your xbel doesn't appear to be huge. the weird thing is that gedit report a list of 411 items and: grep "<mime:mime-type type=\"text" ~/.local/share/recently-used.xbel|wc -l give me 432, with probably some duplicates that we filter look like we fail at filtering non-gedit entries.
Ok, rebuilt. After opening many plain text files: gedit '/home/hussam/Documents/tips.txt' Selector(0x15c0110): constructed - ask recent file list Selector(0x15c0340): constructed - ask recent file list Store(0x15c0340): store dispatcher: Thread:0x161e450, type:RECENT_FILES_LIST Store(0x15c0110): store dispatcher: type:RECENT_FILES_LIST Store(0x15c0340): store dispatcher: Thread:0x161e450, type:RECENT_FILES_LIST, time:6.601516 Store(0x15c0110): store dispatcher: recent list compute Selector(0x15c0110): update_list_cb - type:RECENT_FILES_LIST, length:111 Selector(0x15c0110): populate liststore: scheduled Store(0x15c0110): store dispatcher: type:RECENT_FILES_LIST, time:6.771199 Selector(0x15c0340): update_list_cb - type:RECENT_FILES_LIST, length:111 Selector(0x15c0340): populate liststore: scheduled Selector(0x15c0110): populate liststore: recent files list Selector(0x15c0110): populate liststore: length:5 Selector(0x15c0110): populate liststore: time:0.000843 Selector(0x15c0340): populate liststore: recent files list Selector(0x15c0340): populate liststore: length:5 Selector(0x15c0340): populate liststore: time:0.000674 Store((nil)): store dispatcher: type:RECENT_FILES_LIST Store((nil)): store dispatcher: recent list compute Store(0x160fc00): update_list_cb: type:RECENT_FILES_LIST, length:112 Store((nil)): store dispatcher: type:RECENT_FILES_LIST, time:0.854488 Store((nil)): store dispatcher: type:RECENT_FILES_LIST Store((nil)): store dispatcher: recent list compute Store(0x160fc00): update_list_cb: type:RECENT_FILES_LIST, length:112 Store((nil)): store dispatcher: type:RECENT_FILES_LIST, time:0.689635
opening gedit from dashboard without a file http://pastebin.com/raw.php?i=25EtaULW I saw the zenity 'wait or close application' dialog this time.
with almost seven seconds for 111 files, there's something that's wrong Is the bookmarked files are all local ?
(In reply to sébastien lafargue from comment #13) > with almost seven seconds for 111 files, there's something that's wrong > Is the bookmarked files are all local ? Nope, one entry starts with <bookmark href="https://docs.google.com/spreadsheets/
Deleting the https://docs.google.com entry makes gedit start instantly.
thanx for helping me find the bug and let me do a patch to fix this in the few days max so that we can try again if it fix the prob.