can you get a backtrace (http://live.gnome.org/GettingTraces) with
libglib2.0-0-dbg libgtk2.0-0-dbg nautilus-dbg installed?

The following trace is from  Sebastian Seifert (Bug 306322) and is very good

Confirming because of the duplicate


0xb7bc8561 in __waitpid_nocancel () from /lib/tls/libpthread.so.0

+ Trace 61852

seems to happen in nautilus_bookmark_new ()

setting component to Bookmarks.

looks like it crashes when nautilus attempts to create a bookmark for the
webdav share.

I just installed nautilus-dbg (didnt's know it existed) and generated another
backtrace. The problem rather seems to happen in
nautilus_bookmark_connect_file() than in nautilus_bookmark_new().

Backtrace was generated from '/usr/bin/nautilus'

Using host libthread_db library "/lib/tls/libthread_db.so.1".
`system-supplied DSO at 0xffffe000' has disappeared; keeping its symbols.
[Thread debugging using libthread_db enabled]
[New Thread -1224960864 (LWP 15646)]
[New Thread -1237230672 (LWP 15659)]
[New Thread -1236968528 (LWP 15658)]
[New Thread -1236706384 (LWP 15657)]
[New Thread -1236444240 (LWP 15656)]
[New Thread -1236075600 (LWP 15653)]
[New Thread -1227424848 (LWP 15647)]
0xb7c10561 in __waitpid_nocancel () from /lib/tls/libpthread.so.0

+ Trace 61854

Some more information obtained in the nautilus_bookmark_connect_file() frame,
maybe it is helpful:

(gdb) print *(bookmark->details)
$9 = {name = 0x8370490 "dav: mediacenter.gmx.net on mediacenter.gmx.net", 
  uri = 0x83700c8 "dav://570614@mediacenter.gmx.net", icon = 0x0, file =
0x835d498, scroll_file = 0x0}
(gdb) print *(bookmark->details->file->details)
$10 = {directory = 0x835d018, relative_uri = 0x835d2c8 "/", 
  cached_display_name = 0x83607d8 "dav: mediacenter.gmx.net",
display_name_collation_key = 0x0, 
  info = 0x0, get_info_error = GNOME_VFS_ERROR_NOT_FOUND, monitor = 0x0,
directory_count = 6, 
  deep_directory_count = 0, deep_file_count = 0, deep_unreadable_count = 0,
deep_size = 0, 
  mime_list = 0x8389650, top_left_text = 0x0, display_name = 0x0, custom_icon =
0x0, 
  activation_uri = 0x0, guessed_mime_type = 0x835db78 "x-directory/webdav",
operations_in_progress = 0x0, 
  compare_by_emblem_cache = 0x0, pending_info_providers = 0x0, extension_emblems
= 0x0, 
  pending_extension_emblems = 0x0, extension_attributes = 0x0,
pending_extension_attributes = 0x835d518, 
  unconfirmed = 0, is_gone = 1, loading_directory = 0, get_info_failed = 1,
file_info_is_up_to_date = 1, 
  got_slow_mime_type = 0, got_directory_count = 1, directory_count_failed = 0, 
  directory_count_is_up_to_date = 1, deep_counts_status = 0, got_mime_list = 1,
mime_list_failed = 0, 
  mime_list_is_up_to_date = 1, got_top_left_text = 0,
top_left_text_is_up_to_date = 0, got_link_info = 1, 
  link_info_is_up_to_date = 1, is_thumbnailing = 0, has_volume = 0, has_drive =
0, has_open_window = 1}

I did some more experiments:
I executed nautilus in gdb and set a breakpoint on nautilus_file_changed.
Whenever that breakpoint was hit and file->details->is_gone was set to 1, I set
it to 0. That was only necessary twice. After the second time, the window opened
and no assertion failure :-))).
I could create a folder (named "new"), open this folder, create a text file on
my desktop (test.txt), move "test.txt" into "new", close "new" and reopen "new"
containing "test.txt" while hitting cont in gdb a few dozen times. Strangely,
somewhere inbetween, "new" changed its mime type from x-directory/webdav to
httpd/unix-directory, eliciting the following warning from nautilus:

** (nautilus:15774): WARNING **: No description found for mime type
"httpd/unix-directory" (file is "new"), please tell the gnome-vfs mailing list.
Is this a different bug? I guess so...

A newly created folder "test" on the webdav share has the type
x-directory/webdav, as have the preexisting folders. The preexisting folders
CANNOT be opened. One error I get is:

Couldn't display "dav://570614@mediacenter.gmx.net/Meine%20Dokumente".
The location is not a folder.

However, on those folders that have changed type to httpd/unix-directory, I now get:

Cannot open new

The filename "new" indicates that this file is of type "x-directory/webdav". The
contents of the file indicate that the file is of type "httpd/unix-directory".
If you open this file, the file might present a security risk to your system.

Do not open the file unless you created the file yourself, or received the file
from a trusted source. To open the file, rename the file to the correct
extension for "httpd/unix-directory", then open the file normally.
Alternatively, use the Open With menu to choose a specific application for the
file. 

But probably all of this is unrelated and should be filed in a separate bug once
the "is_gone==1" bug is fixed, right?

I've played around a little, and before I forget, I'll write down what I found:
When the webdav icon is clicked, a NautilusDirectory (with a corresponding
NautilusFile) is created and gnome_vfs_async_get_file_info is eventually called
upon it with get_info_callback as the callback function. It is executed several
times, and there are even more calls of file_info_start which fail because there
is already an operation going on. When the async io completes, the result is
either GNOME_VFS_OK or GNOME_VFS_NOT_FOUND. Usually, it is OK at first but
NOT_FOUND on a later call. I believe there are different NautilusDirectory
objects created for the same URI - is this correct? 

If the result of the async io is GNOME_VFS_NOT_FOUND, the directory's
NautilusFile is marked as is_gone. That leads to the assertion failure of the
above stack trace later.

There are at least two bugs here, I think: the first bug causes the GNOME VFS to
return NOT_FOUND on some occasion, the other bug is the assertion failure in
Nautilus - since the file might have really disappeared before the bookmark
function is called, there seems to be a race.

Hope some of this helps and I'm not talking nonsense.

That x-directory/webdav vs httpd/unix-directory could only happen if the server
says that the mime-type of a given resource is httpd/unix-directory but it
doesnt send the <collection> property as well because we foce the mime type to
be x-directory/webdav for collections. Its either something fishy going on in
the http method (need logs! See #153054) or its totally normal gmx webdav server
brokeness (which wouldnt suprise me in any way).

closing this bug report as obsolete, please reopen if this still happens with a current version of nautilus, like 2.20.x.