GNOME Bugzilla – Bug 455304
comments in ~/.gtk-bookmarks cause gtk applications to crash
Last modified: 2008-10-07 10:41:59 UTC
Steps to reproduce: 1. cat >>~/.gtk-bookmarks<EOF file:///home/jhunt/work file:///home/jhunt/work/svn/trunk file:///home/jhunt/tmp ;smb://192.168.0.6/media ;ssh://192.168.0.2/data EOF 2. Fire up an application using GTK (gedit, openoffice, etc). 3. File->Open 4. Application will crash. Stack trace: n/a. Other information: Admittedly, I'm not sure if specifying a comment by using a leading semi-colon is valid, but either way, the application should not crash - gtk should ignore lines it cannot parse, allowing the application to continue, and allow the user the change to select a file to open.
Thanks for taking the time to report this bug. Can you get us a stack trace? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance!
No symbols on this machine, but I pulled the following from reproducing the problem running edit in GDB: Program received signal SIGSEGV, Segmentation fault.
+ Trace 151249
Thread NaN (LWP 19478)
As soon as the semicolons are removed the crash disappears.
reassigning to gtk
something "funny" is when the text after the semi-colon is not a path, the application doesn't crash. ################## The backtrace ##########################
+ Trace 152648
Thread 1 (Thread -1228503376 (LWP 14449))
the .gtk-bookmarks file format is completely internal to gtk+ and should *never* be modified by the user (or any other application, for that matter) until gtk+ exposes some API to do so. unfortunately, some other applications started reading or writing it (the panel and nautilus) but no guarantees have ever been made. in short: the user should *not* touch the file. there are plans of switching to a xbel-like format, accessible through the GBookmarkFile API, but some issues are still pending.
Hi Emmanuele, So this bug can be closed as INVALID ?
yes. if you feed garbage to gtk+ then no assumptions can be made. you can always craft some malformed line that causes a crash, and this case is no different.
Even though we don't support comments, GTK+ should not crash --- it should simply ignore the offending lines. Reopening. [Shouldn't we just get a NULL back from gnome_vfs_uri_new and say "this is an invalid URI"?]
Seems to work fine with current trunk, with both the unix and gnome-vfs backends
I had this bug in ubuntu hardy because of an incorrectly formatted line in ~/.gtk-bookmarks. The line was /mnt/directory Removing that line got the bug disappeared
That line was entered through the normal bookmark edit dialog, instead of selectin the directory in the directory tree on the left, I had entered the directory directly without the file:/// prefix in the position textbox. The bookmark add dialog shouldn't close if there is an incorrectly formatted position. If this isn't fixed in trunk, the bug shouldn't be left closed.
Please don't tell us "Ubuntu Hardy" but the exact gtk+ version you have installed. Thanks.
~$ dpkg -l|grep libgtk2.0 ii libgtk2.0-0 2.12.9-3ubuntu5 ii libgtk2.0-bin 2.12.9-3ubuntu5 ii libgtk2.0-cil 2.12.0-2ubuntu3 ii libgtk2.0-common 2.12.9-3ubuntu5
(In reply to comment #10) > I had this bug in ubuntu hardy because of an incorrectly formatted line in > ~/.gtk-bookmarks. > > The line was > > /mnt/directory > > Removing that line got the bug disappeared I think that's this one, fixed in 2.14: Bug 541645 – gtkfilechooserdefault segfaults when bookmark does not contain ://