GNOME Bugzilla – Bug 358393
gtk_file_system_volume_get_base_path
Last modified: 2006-09-30 14:26:44 UTC
What were you doing when the application crashed? Opening preferences Distribution: Fedora Core release 5.92 (FC6 Test3) Gnome Release: 2.16.0 2006-09-04 (Red Hat, Inc) BugBuddy Version: 2.16.0 Memory status: size: 380669952 vsize: 380669952 resident: 15343616 share: 11001856 rss: 15343616 rss_rlim: -1 CPU usage: start_time: 1159569146 rtime: 11 utime: 9 stime: 2 cutime:0 cstime: 1 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/usr/bin/sound-juicer' (no debugging symbols found) Using host libthread_db library "/lib64/libthread_db.so.1". (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 46912504578544 (LWP 4730)] (no debugging symbols found) 0x000000320580d96f in waitpid () from /lib64/libpthread.so.0
+ Trace 73621
Thread 1 (Thread 46912504578544 (LWP 4730))
Thanks for the bug report. Unfortunately, that stack trace is not very useful in determining the cause of the crash. Can you get us one with debugging symbols? Please see http://live.gnome.org/GettingTraces for more information on how to do so.
I had just changed the directory to a subdirectory of my home directory. Oddly, it still extracts to the new directory fine, it just crashes if I attempt to enter preferences. Stack trace using gdb: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46912504578544 (LWP 4920)] 0x0000003204c74f60 in strcmp () from /lib64/libc.so.6 (gdb) thread apply all bt
+ Trace 73622
Thread 1 (Thread 46912504578544 (LWP 4920))
John, stacktraces collected by bug-buddy usually are fine. The issue here is, that neither of these stacktraces are really useful, cause they don't have debugging symbols. If you could install the relevant packages containing the debugging symbols (for sound-juicer and some basic GNOME libs), reproduce the crash and paste or attach the resulting stacktrace here, that would be most helpful. Thanks. Also, of course, thanks for the additional information. :)
The thing is, sometimes it doesn't call bug-buddy when it crashes. I had installed the sound-juicer debuginfo packages for the second stack trace. Here's one with the debugging symbols for gtk and glib. This is after using gconftool to unset the uriinfo key (at which point it works fine) and then crashing upon attempting to change the path. Looks like it's segfaulting in strcmp. Presumably it's reading off the end of the string for the uriinfo key that tells it where to put the extracted files. Or it's crashing off of what it's trying to compare it to. Do you need any more symbols? Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46912504578544 (LWP 5737)] 0x0000003204c74f60 in strcmp () from /lib64/libc.so.6 (gdb) thread apply all bt
+ Trace 73628
Thread 1 (Thread 46912504578544 (LWP 5737))
base_path, which is set by base_path = gtk_file_system_volume_get_base_path (priv->fs, data) at gtkfilechooserbutton.c:2212 is definitely being set to a NULL pointer, which crashes strcmp.
Great, thanks John. Good investigation. :-) Moving to GTK+. Reopening and Confirming.
Actually, just like bug 357714, I believe this to be a duplicate of bug 357364. Thanks again, John.
*** This bug has been marked as a duplicate of 357364 ***
Nice find in comment #5 : I checked and it's the only place in the file where base_path is used without being checked afterwards. A possible fix should be to replace : row_found = (paths && paths->data && gtk_file_path_compare (base_path, paths->data) == 0); with : row_found = (base_path && paths && paths->data && gtk_file_path_compare (base_path, paths->data) == 0); (I'm assuming the next line with gtk_file_path_free is a g_free and won't give issues with NULL)
BTW, this is definitely gtk+-2.10.4, so in addition to bug 357364, it could be related to bug 358405