Steps to reproduce:
I was previously browsing a directory which i subsequently deleted and gthumb
started crashing constantly on startup. I've tracked it down to a pretty obvious
coding bug (naughty naughty) which passes NULL to strcmp(). Note even though
i've set the 'use_startup_location' pref to false, it still traverses this
codepath. Surely this is also incorrect. Anyhow here is the steps to reproduce..

1. Check that 'use_startup_location' is false
laptop ~% gconftool-2 -g /apps/gthumb/general/use_startup_location
false

2. Set a bogus directory (i.e. simulating a directory which existed previously,
but now removed - it's a real life scenario guys)
laptop ~% gconftool-2 -s -t string /apps/gthumb/general/startup_location /x

3. Make sure it's set correctly
laptop ~% gconftool-2 -g /apps/gthumb/general/startup_location
/x


Stack trace:
Then run gdb on the binary (i'm using latest coed from CVS so this bug still exists)

laptop ~% gdb gthumb
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library
"/lib/libthread_db.so.1".

(gdb) r
Starting program: /usr/local/bin/gthumb
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 29047)]
[New Thread 32769 (LWP 29050)]
[New Thread 16386 (LWP 29051)]
[New Thread 32771 (LWP 29052)]
[New Thread 49156 (LWP 29053)]
[New Thread 65541 (LWP 29084)]
[New Thread 81926 (LWP 29085)]
[New Thread 98311 (LWP 29086)]
[New Thread 114696 (LWP 29087)]
[New Thread 131081 (LWP 29088)]

Program received signal SIGSEGV, Segmentation fault.

+ Trace 64910

So let's go back one stack frame to see what's going on

(gdb) b go_to_directory_continue
Breakpoint 1 at 0x8082259: file gth-browser.c, line 7557.
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/local/bin/gthumb
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 29092)]
[New Thread 32769 (LWP 29096)]
[New Thread 16386 (LWP 29097)]
[New Thread 32771 (LWP 29098)]
[New Thread 49156 (LWP 29099)]
[New Thread 65541 (LWP 29130)]
[New Thread 81926 (LWP 29131)]
[New Thread 98311 (LWP 29132)]
[New Thread 114696 (LWP 29133)]
[New Thread 131081 (LWP 29134)]
[Switching to Thread 16384 (LWP 29092)]

Breakpoint 1, go_to_directory_continue (dir_list=0x827d0c0, data=0x811a510) at
gth-browser.c:7557
7557    {
(gdb) p *dir_list
$1 = {path = 0x0, try_path = 0x85f3fd0 "/x", list = 0x0, file_list = 0x0,
list_store = 0x8147098, list_view = 0x815b378, root_widget = 0x80e0118,
text_renderer = 0x81943f0, show_dot_files = 0, single_click = 0, hover_path =
0x0, old_dir = 0x0, done_func = 0x8082250 <go_to_directory_continue>, done_data
= 0x811a510, dir_load_handle = 0x0, result = GNOME_VFS_ERROR_NOT_FOUND}
(gdb)

So it's clear from the code in gth-browser.c we shouldn't be here. Note we
shouldn't even get to the strcmp() code path since we are checking 
 
        if (dir_list->result != GNOME_VFS_ERROR_EOF) {

but note from gdb when i printed out *dir_list, the result is actually
GNOME_VFS_ERROR_NOT_FOUND !!!!


So 2 points,

1. GNOME_VFS_ERROR_NOT_FOUND should also be tested in go_to_directory_continue !

2. Why are we in this codepath if i'm specifically requesting the gconf 
'use_startup_location' as false ?

Other information: