309499 - GTK2 File Picker hangs SeaMonkey

Status: RESOLVED DUPLICATE of bug 305970

(Core :: Widget: Gtk, defect)

Description

[Xanthor Sccas]

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:  
Hangs

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...

Comment 1

[Andrew Schultz]

worksorme with linux seamonkey trunk 2005092103 and 1.0a (and gtk 2.6.10, FC4).
can you grab a stack trace during the hang?

Comment 2

[Xanthor Sccas]

Attachment: Stack

From gdb (I hope it's what you need)

Comment 3

[Andrew Schultz]

your stack includes /usr/local/seamonkey1.0a/components/libmsgimap.so indicates
imap is doing something during the hang.  Do you see this invoking the
filepicker from the browser?

Comment 4

[Xanthor Sccas]

Attachment: another stack (from a "file" input)

Yes, it occures from a browser window, without any mail window opened.

Comment 5

[Andrew Schultz]

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)

Comment 6

[Xanthor Sccas]

Attachment: stack with all threads

I think the interesting thread is the first one.

Comment 7

[Andrew Schultz]

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:
http://talkback-public.mozilla.org/talkback/fastfind.jsp

Comment 8

[Xanthor Sccas]

(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)

Comment 9

[Andrew Schultz]

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.

Comment 10

[Xanthor Sccas]

Yes, it was in the queue, as I said.
I past the result here : http://rafb.net/paste/results/FNW1B824.html

Comment 11

[Andrew Schultz]

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

Comment 12

[Andrew Schultz]

actually, there's already a bug for this

*** This bug has been marked as a duplicate of 305970 ***