Closed Bug 309499 Opened 18 years ago Closed 18 years ago

GTK2 File Picker hangs SeaMonkey


(Core :: Widget: Gtk, defect)

Not set





(Reporter: xanthor+bz, Unassigned)


(Keywords: hang)


(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050913 SeaMonkey/1.0a
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050913 SeaMonkey/1.0a

Most of times, when I click on a browse button, the file picker is launched, but
hangs. SeaMonkey doesn't respond anymore, and need to be terminated.

I'm using GTK 2.6.10 on a Debian sid, with Xfce4 Desktop Manager

Reproducible: Sometimes

Steps to Reproduce:
1. Launch the file picker ("file" input, attachment of Mail client...)
Actual Results:  

Expected Results:  
No hangs

I've test with other GTK2 browsers on my system (like Epiphany), and the problem
doesn't occure. So I think this doesn't come from my GTK2 lib...
Version: unspecified → 1.8 Branch
worksorme with linux seamonkey trunk 2005092103 and 1.0a (and gtk 2.6.10, FC4).
can you grab a stack trace during the hang?
Keywords: hang
Attached file Stack
From gdb (I hope it's what you need)
your stack includes /usr/local/seamonkey1.0a/components/ indicates
imap is doing something during the hang.  Do you see this invoking the
filepicker from the browser?
Attached file another stack (from a "file" input) (obsolete) —
Yes, it occures from a browser window, without any mail window opened.
That looks like a pretty normal stack, but appears to be one of the helper
threads.  Can you look at the other threads and grab stacks for the main one (or
anything that looks interesting).

(gdb) info threads
should list the threads and
(gdb) thread 3
should switch to thread #3 (or whichever one you want)
Attached file stack with all threads
I think the interesting thread is the first one.
Attachment #197316 - Attachment is obsolete: true
That's a very strange stack.  And unfortunately without symbols.  Does this
occur with trunk builds as well?  If so, wait for the hang, and then

% kill -SEGV _pid_of_seamonkey_

Then submit a talkback report, look up the talkback ID by running
seamonkey_dir/components/talkback/talkback and then look it up here:
(In reply to comment #7)
> Does this occur with trunk builds as well? 
Yes : tested with Gecko/20051115 SeaMonkey/1.5a

> % kill -SEGV _pid_of_seamonkey_
> Then submit a talkback report
TB12020143Z (still in the queue)
talkback says:
> No entry for Incident ID: 12020143 (it does not exist, the id is too big)
> The most recent incident id submitted is 12003312.
Yes, it was in the queue, as I said.
I past the result here :
ok, thanks.

So the gtk2 filepicker kindly informs us that the theme /changes/ (every time you invoke the file picker).  I've noticed a few-second freeze when bringing up the dialog and this is probably it (I verified that I hit nsWindow::ThemeChanged in gdb).  Are you sure that SeaMonkey never recovers if you wait long enough?

==> gtk
Assignee: guifeatures → nobody
Component: XP Apps: GUI Features → Widget: Gtk
Ever confirmed: true
Product: Mozilla Application Suite → Core
QA Contact: gtk
Version: 1.8 Branch → Trunk
actually, there's already a bug for this

*** This bug has been marked as a duplicate of 305970 ***
Closed: 18 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.