Using your instructions, I can duplicate using file-roller 2.9.92.  Here's the
first part of the stack trace:

Backtrace was generated from '/opt/gnome2/bin/file-roller'

+ Trace 57013

I'll attach the full stack trace in an attachment.

Created attachment 38878 [details]
Full stacktrace

Oh, I forgot.  Here's the assertion shown in the terminal when the crash occurs:

Gtk-ERROR **: file gtkfilechooserdefault.c: line 1792 (queue_edited_idle):
assertion failed: (!impl->edited_idle)
aborting...

bugzilla.ubuntu.com has a similar bug on firefox:
https://bugzilla.ubuntu.com/show_bug.cgi?id=7552

That seems to be a gtk fileselector issue, reassiging

Is this a duplicate of bug 170127?

*** Bug 170127 has been marked as a duplicate of this bug. ***

*** Bug 170950 has been marked as a duplicate of this bug. ***

*** Bug 170991 has been marked as a duplicate of this bug. ***

*** Bug 171120 has been marked as a duplicate of this bug. ***

*** Bug 168964 has been marked as a duplicate of this bug. ***

*** Bug 168651 has been marked as a duplicate of this bug. ***

I can't reproduce this bug in ubuntu with

file-roller 2.10.0
gtk 2.6.4-0ubuntu1

nor with mozilla-firefox.
Maybe it has been already resolved?

*** Bug 170580 has been marked as a duplicate of this bug. ***

The latest DUP is 2.10.x on Ubuntu

however I cannot reproduce on GARNOME 2.10.0.1
file-roller 2.10.0

I can't reproduce it any more either (I have updated packadges since the
original report).

It seems that this bug is AMD64 specific, according to the Ubuntu bug report:
https://bugzilla.ubuntu.com/show_bug.cgi?id=7552 . I can confirm it is still
happening on AMD64.

Frederik: No it's not.  I duplicated on my system, and the original stack trace
obviously isn't from AMD64 either.

I am having this problem on Ubuntu's Hoary (Array 7) too, running an AMD Athlon
2000 processor. Could it be related to optimization flags during the compilation
of GTK. The crash is not limited to AMD64 processors, but seems to be limited to
AMD processors. Just a thought...

*** Bug 171985 has been marked as a duplicate of this bug. ***

I am running on celeron, so I doubt it is AMD specific.

*** Bug 171161 has been marked as a duplicate of this bug. ***

*** Bug 172042 has been marked as a duplicate of this bug. ***

Elijah, can you still duplicate this?  I can't :(

If so, what's your platform, versions, etc?

I did duplicate it once, but I can't seem duplicate it now and  I haven't
updated anything.  It may be tarball or zipfile specific.  The problem is, I was
most likely to have used whatever tarball or zipfile was provided in another bug
report for some other test (this was just one in a series of bugs I was
triaging).  Anyway, I'm runing on x86, Fedora Core 2, with Gnome installed via
jhbuild using the gnome-2.10 moduleset.  It appears that gtk+ was pulled from
cvs on March 10th, while file-roller was pulled from cvs on March 4th.  I'll see
if I can find a tarball or zipfile or other archive that I can get this crash to
occur with...

Okay! Watch Ubuntu's thread on this bug:
https://bugzilla.ubuntu.com/show_bug.cgi?id=7552

Dino wrote that it only happens when you create a folder in your home directory,
e.g. /home/$user. I've checked this, and he is right. I am not experiencing any
problems while creating a folder in another directory.

Found an unreliable way to duplicate it:

- start gedit in your home directory
- type something
- Hit C-s
- Open the "Browse for other folders" expander
- Hit the "Create folder" button
- ... the uncertainty comes here ... unfocus the window, or just wait a bit
- crash

This will only work only if you are in your home directory.

What happens is this:

When the cell being edited stops editing, the file chooser queues an idle
handler to create the new folder and switch to it.  There's a good reason why
it's done in an idle, but I don't remember the details right now --- I'm sure
it's explained in the ChangeLog.

1. In the last step, where you unfocus the window, the cell stops editing and
the file chooser calls queue_edited_idle() for the first time.
2. We go back to the main loop.
3. GConfd changes something under ~/.gconfd, and so the mtime of this changes. 
The file chooser gets notified about this change.
4. The file system model emits row_changed, which eventually gets pick up by the
tree view.
5. The tree view stops editing because a row was changed (this is in
gtktreeview.c:7045).
6. Due to this, the file chooser gets notified again that the cell stopped
editing, so it calls queue_edited_idle() again.  Since we already have an idle
handler, the assertion fails.

Some thoughts about this:

- The tree view should probably not stop editing if the row that changes is
different from the row being edited.  This bug mentions this and provides a
patch: http://bugzilla.ximian.com/show_bug.cgi?id=59669

- The file chooser could probably just monitor the case where the cell editing
is *canceled*, rather than terminated in any way, and cancel its idle handler in
that case.  Or something like that.  I'll do this for now.

I'm attaching a stack trace that shows the problem induced by a change in ~/.gconfd.

Created attachment 39451 [details]
Stack trace that shows the bug triggered by a spurious change in a file under ~

Note that the stack trace above does not show where queue_edited_idle() gets
called for the first time.  It gets called in a previous iteration of the main
loop, so it doesn't appear in this particular stack trace.

Fixed on HEAD and gtk-2-6.

2005-03-30  Federico Mena Quintero  <federico@ximian.com>

	Fix #170755:

	* gtk/gtktreeview.c (gtk_tree_view_row_changed): Only stop editing
	if the row which changed is the same as the row being edited.

*** Bug 172053 has been marked as a duplicate of this bug. ***

*** Bug 306734 has been marked as a duplicate of this bug. ***