GNOME Bugzilla – Bug 310270
crash in file selector while open a directory
Last modified: 2005-12-18 22:15:12 UTC
If I remove the libgnome-vfs.so from the gtk+/2.4.0/filesystem subdirectory the crash does not happend. The weired thing is that it happends only in some directories, here is the backtrace:
+ Trace 61711
According to simple-dup-finder this is a unique stack trace.
Could you please attach your ~/.gtk-bookmarks? When the crash happens inside gdb, could you go up to frame 1 (in shortcut_find_position) and do this: p (char *) path p (char *) base_path p volume I need the output from those three commands.
Created attachment 49200 [details] gtk-bookmarks file
I forgot to say that this happends when I select open directory from the menu, if i select open a file eog crashesh inmediately, and shows this in the console (eog also shows this when opening a directory): (eog:7101): Gtk-CRITICAL **: gtk_file_system_path_is_local: assertion `path != NULL' failed (eog:7101): Gtk-CRITICAL **: gtk_file_system_path_is_local: assertion `path != NULL' failed ------------------------- I'm not sure how to go to frame 1. This is what i did, i put a break point at shortcut_find_position and then ran the program. This is what i got: Breakpoint 1, shortcut_find_position (impl=0x81e1020, path=0x824cd10) at gtkfilechooserdefault.c:1915 1915 if (!gtk_tree_model_get_iter_first (GTK_TREE_MODEL (impl->shortcuts_mo del), &iter)) (gdb) p (char *) path $1 = 0x824cd10 "file:///home/diego/Desktop/My%20Photos" (gdb) p (char *) base_path No symbol "base_path" in current context. (gdb) p volume No symbol "volume" in current context.
Ok, i just learned how to do this: (gdb) frame 1
+ Trace 61754
$1 = 0x81ff208 "file:///home/diego/Desktop/My%20Photos" (gdb) p (char *) base_path $2 = 0x0 (gdb) p volume $3 = (GtkFileSystemVolume *) 0x81e8190
base_path is null!? This indicates that gnome-vfs returned a NULL activation uri for a volume or a drive. Alex, do you know why this may happen?
That is strange. With the recent HAL patch we do generate drives for devices where we don't yet know the mountpoint (not in fstab). However, these should return "" as the activation uri.
I'm using HAL and gnome-vfs from CVS HEAD, if that helps. I'm also seeing some strange things after updating. For example, the computer window has this label for the CD writer: "CD-RW(null) Drive" and the CD reader has something like that also. I don't know if it is related.
the label issue is #310296
I have found the source of all my problems and crashes, it was some stale fdi files that where causing all the problems. Even those (null) string in the middle of the device names. Now everything is back to normal. Sorry for the time I made you spend on this issue.
No problem :)
I've the same crash here, and even if there is an incorrect hal file the fileselector should not crash, reopening
Today, when i turned on the computer everything started crashing again, I don't really know what the difference is. Because i don't remember changing anything.
setting the milestone to 2.12, gedit crashes as soon as I click on "open" here
Eog also crashes, I have been trying several programs. The only difference that i can see between the programs that crash and the ones that don't crash when opening a file is that the ones that crash have both of my CD drives (reader and writer) and the floppy in them. The crash happends after this is shown and before the GtkTreeView on the right side is filled (there is nothing in there). Other programs like epiphany or abiword, don't crash but also show in the console this warning three times: (gedit:4792): Gtk-CRITICAL **: gtk_file_system_path_is_local: assertion `path != NULL' failed Don't know if this is of help.
*** Bug 311859 has been marked as a duplicate of this bug. ***
I've this crash too. Just to sommarize my experience: * the crash is related to gnome-vfs+hal - compiling gnome-vfs using --enable-hal=no or killing haldaemon while session is running, everithing works fine * the crash occurs only in some applications (eog, gedit) * other applications (gnome-search-tool, epiphany) don't crash, but in bookmark list are showed only "Home" "Desktop" and "File system" entries. There are no entries for removable devices * instead connected server are showed #-| * the Gtk-CRITICAL message is printed for both crashing and not-crashing apps * the save dialog for gedit and eog shows only Home, Desktop and FS entries, but don't crash * the open dialog for gedit and eog crash while loading the list of files in home; meanwile (well in 1/100 of sec before crashing) all entries in bookmark list are showed * oh, my .gtk-bookmarks is empty * "Program terminated with signal 11"
Created attachment 49991 [details] Another backtrace This bactrace come from gedit. Please note the different odd string at #19 (I will away until september. Happy hacking and fixing. And happy holidays to me :-P)
* gnome-screenshooter seems to work: the list on location on chooser-button is still Home, Desktop and File system, but choosing "Other..." the chooser dialog shows removable drives provided by HAL * Drive names provided by libhal are no translated (using it-IT locale, and, yes, it.po exist in hal): could be related or it's another bug?
*** Bug 312074 has been marked as a duplicate of this bug. ***
just to finish my notes: * evince is the third application to crash opening files: note that evince, gedit and eog have the ability to open non local files via gnome-vfs * with HAL enabled (at compile time or with haldaemon running) trahs:// location don't work: both the item on desktop and the applet stay "empty" when you move a file to trash (via d'n'd or nautilus command). The files are physically moved to $HOME/.Trash directory, but trash:// seems disconnected. PS: yeah, I know this latest entry is not related to file selector, but, as I said, disablig HAL all those issues disappear. I really suppose it's a gnome-vfs+HAL issue.
file-chooser/gtkfilesystemgnomevfs.c: gtk_file_system_gnome_vfs_volume_get_base_path () returns a NULL uri for non-mounted volume. Example: (gedit:5552): Gtk-CRITICAL **: gtk_file_system_path_is_local: assertion `path != NULL' failed gnome_vfs_drive_get_display_name: CD-ROM/DVD-ROM Drive gnome_vfs_drive_get_device_path: /dev/hdd uri: (null) gnome_vfs_drive_get_display_name: Floppy Drive gnome_vfs_drive_get_device_path: /dev/fd0 uri: (null) that's because "uri = gnome_vfs_drive_get_activation_uri (GNOME_VFS_DRIVE (volume));" is used, and according to the gnome-vfs sources: " } else { /* This sucks but it doesn't make sense to talk about the activation_uri if we're not mounted! * So just set it to the empty string */ drive->priv->activation_uri = g_strdup (""); }" maybe gnome_vfs_drive_get_device_path () should be used here?
I've opened #312171, on gnome-vfs, about gnome_vfs_drive_get_activation_uri() beeing not coherent.
Does the patch in bug 308475 fix this problem?
*** Bug 312148 has been marked as a duplicate of this bug. ***
no, libgnomeui 2.11.1 has this patch, the issue is with the " else { uri = gnome_vfs_drive_get_activation_uri (GNOME_VFS_DRIVE (volume)); " case
I confirm that this bug is due to incorrect handling of non-browsable devices. Apparently I had my swap partition in /etc/fstab as mount point "none", but until i figured this out i wondered why I had a device named "none" in computer:/// - well now I can confirm it. after a change of this and a reboot the device is gone and gedit doesn't crash. I can do fine without a my swap parition for now, but I can only agree with the issue severety rating "critical".
*** Bug 312571 has been marked as a duplicate of this bug. ***
*** Bug 312933 has been marked as a duplicate of this bug. ***
*** Bug 312372 has been marked as a duplicate of this bug. ***
*** Bug 312923 has been marked as a duplicate of this bug. ***
OK - this is an interesting bug - and it just knackered OO.o too ;-) From a brief glance - here is what is happening: a) a Gnome 2.8 gnome-vfs daemon is running on the desktop somehow, + that daemon has a difference in the IDL to 2.0: + adding a 'boolean must_eject_at_unmount' b) we have 2 people compiled with different views of the same interface => what is on the wire doesn't match what we should de-marshal. Bear in mind that in this case - CORBA can do nothing, there is no way of knowing what to do here since the types of the arguments are not marshalled -just the data. [ this is 1 strength of D/BUS IMHO - although it's not in fact taken advantage of there (yet);-] c) The ORB *should* fail gracefully when what is on the wire doesn't match what it is expecting. To some extent we already do this: we find we don't have enough data to de-marshal [ remember the 2.8 version is going to send 1 octet too few ], and so we return TRUE from corba-any.c (ORBit_demarshal_value) line ~686 - we also NULL the ->_buffer - *but* we don't clobber the length of the sequence. I've added that fix. Unfortunately ORBit_demarshal_arg ignores the error value - so we don't get the exception we should after the stub completes - I'll fix that: now we'll get an exception inside the gnome-vfs code. FWIW - I'd -strongly- recommend creating a new / parallel sub-classed structure: struct Drive2 { Drive parent; ... extra data ... any expansionIsGood; }; and a new method to return that to be more safe / fool-proof. HTH.
Committed: +2005-08-11 Michael Meeks <michael.meeks@novell.com> + + * src/orb/orb-core/corba-any.c (ORBit_demarshal_arg): + propagate the error condition we laboured hard to get right + to our caller. + (ORBit_demarshal_value): when sequence de-marshalling + dies, nail the length as well as freeing the buffer. + Fixes #310270# Now - of course, it's a mystery as to why this was causing grief in a homogenous Gnome-2.12 setup.
*** Bug 313190 has been marked as a duplicate of this bug. ***
So - more information - removing: gtk_file_chooser_set_local_only (chooser, FALSE); stops the crash - so clearly it's isolated in the libgnomeui piece. The proximate crash is just a trivial NULL strcmp, in more depth we get a NULL base_path pointer back from: base_path = gtk_file_system_volume_get_base_path (impl->file_system, volume); exists = strcmp (gtk_file_path_get_string (path), gtk_file_path_get_string (base_path)) == 0; and segv the next line. Trivial patch attached - also adds some other probably useful preconditions. Still spews warnings of course - but appears to function without crashing.
Created attachment 50596 [details] [review] more preconditions ...
This patch fixes the bug for me too.
Thanks Michael. I've committed your workaround.
David - when you say fixes it - I still get loads of warning spew - and am suspiciously missing any network places type icons in my shortcuts - indeed, any way to use non-local file-systems - which ( I believe ) is prolly part of the problem. ie. this is very much a non-fix ;-) Thanks for committing that Matthias.
If base_path really can be NULL, then we need to cover more cases. Attaching patch.
Created attachment 51656 [details] [review] Gtk+ patch to handle base_path being null in more places.
commited that.
I can still reproduce this. The crash happens in every app, with or without HAL running, when opening any directory, except for home (home==desktop). Interestingly, only selecting a directory and adding it to the bookmarks, then opening it from there works OK.
Victor: With what version of gtk+? (As far as I can tell from the ChangeLog, Alex's patch was committed last Friday and isn't part of an official gtk+ release yet)
(Bumping up priority/severity, because this seems to be the only issue left on the showstoppers list--it might be fixed or worked around sufficiently from the above patches, but I can't tell just from reading the bug.)
I don't have time to work on this; there's a deadline for Suse 10 at work and it's keeping me busy.
Elijah: gtk+ from jhbuild, (-r gtk-2-8), it has the second part of Alex's patch, and I've merged the first one too. Still no luck. PS: just to make sure, we are talking about the patch in comment #41, right?
victor: How does your ~/.gtk-bookmarks file look?
Also, do you get an identical backtrace to the one at the top of the bug?
If someone who can reproduce this could get a backtrace at the first warning before the crash that would be interesting. Set a breakpoint in g_log, or run with --g-fatal-warnings.
Alex: My '.gtk-bookmarks' is empty. Adding bookmarks or removing the file makes no difference. Starting program: /usr/local/opt/gnome2/bin/eog /opt/gnome2/bin/eog --g-fatal-warnings
+ Trace 62732
Is this useful?
Interesting fact: ro_RO.UTF-8 -> crash LANG=C -> works ok
I think this is a translation bug. #: gtk/gtkfilechooserdefault.c:2394 msgid "Add the current folder to the bookmarks" msgstr "Adaug$-1 £ directorul òþ%sòý la favorite" See how the translation has %s, but not the original string. This causes it to read a random pointer as a string to print...
Yes, it is. Changing the string fixes it. Thanks Alex!
Ah, msgfmt -c did not catch this because xgettext did not mark the string as c-foramt. It will in the future.
Matthias told me that "with [gtk+] 2.8.3 everybody should see warnings about base_path being NULL, but the crash problem should be language-specific and only affect ro." So, dropping the priority/severity and removing from the showstopper list. :-)
For reference: bug #308475 is the libgnomeui part, bug #312171 is the gnome-vfs part.
I have not found the specific translation string containing "%s" nor any similar string. "directorul" only appears in ro.po - i have checked all "%s" in that file manually. Looks like the second patch has been applied, but the status is not set. Setting to "committed" Assuming this has been fixed, marking FIXED.