504670 - Firefox occasionally hangs on first menu access due to sound

Status: RESOLVED WORKSFORME

(Core :: Widget: Gtk, defect, P3)

Description

[shawnfennell]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5

The program will hang the first time I try to use the menus(menubar or right-click). Program will completely hang for about 2-5 mins.  After this period, the requested menu will pop up(even if another program has focus) and any further attempts to use the menus will work normally.

This has been tested with several window managers(KDE, fluxbox, XFCE).

Reproducible: Always

Steps to Reproduce:
1.Start Program
2.Attempt to access menu
3.
Actual Results:  
Program becomes unresponsive for 2-5 minutes.

Expected Results:  
Program displays menus.

I am using the Adblock Plus(1.0.2) extension.  Disabling it does not seem to affect the issue.

This has been tested using several window managers(KDE, fluxbox, XFCE).

about:buildconfig output follows:

about:buildconfig

Source

Built from http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a625a31a0ad1
Build platform
target
i686-pc-linux-gnu

Build tools
Compiler 	Version 	Compiler flags
/tools/gcc/bin/gcc 	gcc version 4.1.2 20061011 (Red Hat 4.1.1-29) 	-Wall -W -Wno-unused -Wpointer-arith -Wcast-align -W -Wno-long-long -pedantic -gstabs+ -fno-strict-aliasing -pthread -pipe -DNDEBUG -DTRIMMED -Os -freorder-blocks -fno-reorder-functions -finline-limit=50
/tools/gcc/bin/g++ 	gcc version 4.1.2 20061011 (Red Hat 4.1.1-29) 	-fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -pedantic -gstabs+ -fno-strict-aliasing -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -Os -freorder-blocks -fno-reorder-functions -finline-limit=50

Configure arguments
--enable-application=browser --enable-optimize --enable-update-channel=release --enable-update-packaging --disable-debug --disable-tests --enable-official-branding

Comment 1

[Ria Klaassen (not reading all bugmail)]

Makes me think of Bug 498089. Although that was seconds, not minutes. The Linux equivalent could be Bug 419275.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Reporter, could you please run a test with a fresh profile? Does it solve the problem you see?

http://support.mozilla.com/en-US/kb/Managing+profiles

If yes, we should investigate why your current profile is somewhat broken. Thanks.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

First I also thought of bug 504900 but this bug is reported against Linux so the .net Framework add-on will not be present.

Comment 4

[Marco Maggi]

I confirm the same problem of the original poster.

Trying Firefox 3.5.1  on a i686-pc-linux-gnu under Slackware
Linux.   I  installed  "firefox-3.5.1.tar.bz2".   Never  had
problems  with  previous releases  and  Firefox 3.0.11  runs
fine.

When launching  "firefox" the  window is displayed  with the
"Firefox  Updated" tab (the  first time)  and my  start page
tab.  I  can browse them with no  problems, following links.
The buttons on the tool  bar appear to work correctly, I can
go forward and backward, go home, open a new tab.  Scrolling
with the  keyboard works; moving  the focus over  links with
tab works.

At startup, before I do anything, "firefox" prints:

*** e = [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]"  nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)"  location: "JS frame :: chrome://browser/content/utilityOverlay.js :: getShellService :: line 312"  data: no]
[SmartNamer] updateEntry()

I see  that the  Net is accessed;  this is normal  because I
have a weather forecast  extension which looks for data, and
displays it  correctly, but the  access is longer  than with
3.0.11.   I have  no  tool to  make  a through  measurement,
though.  (I  hope I  do not have  to dive into  iptables for
this.)

When I click for a menu it prints again:

*** e = [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]"  nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)"  location: "JS frame :: chrome://browser/content/utilityOverlay.js :: getShellService :: line 312"  data: no]

and it freezes.  After minutes  it comes back to life Trying
to open a menu with Alt-f, for example, does the same thing.

I have installed the following Slackware packages:

xorg-server-1.4.2-i486-1
xorg-server-xvfb-1.4.2-i486-1
gtk+-1.2.10-i486-4
gtk+2-2.12.12-i486-1
glib-1.2.10-i486-3
glib2-2.16.6-i486-1
pango-1.20.5-i486-1

I  do not use  a desktop  environment, I  run Fvwm  from the
Slackware package:

fvwm-2.4.20-i486-1

Firefox 3.5 (the first release) had the same problem.

Comment 5

[Marco Maggi]

Forgot to say that creating a new profile changes nothing.

Comment 6

[Marco Maggi]

Starting in off-line mode (with the OffLine add-on) changes nothing.

Comment 7

[Ria Klaassen (not reading all bugmail)]

Have you already tried a reinstallation in a newly created folder?

Comment 8

[Marco Maggi]

"Ria Klaassen" wrote:
> Have you already tried a reinstallation in a newly created folder?

What does this mean? I have unpacked the binary distribution archive under "/opt/firefox/3.5.1" and it seems that the executable finds all the libraries. Or I would not be able to write this right now.

Maybe do you mean to create a new user and start firefox with that? Or renaming "~/.mozilla" to some other thing and start firefox without the old stuff?

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

There is a similar problem when building Firefox on your own. See bug 383348. I don't know if it is somehow related.

Would you be able to test the release candidates and beta builds of Firefox 3.5 to check if it has been regressed in the development cycle of Firefox 3.5? That would be a great help.

Comment 10

[Marco Maggi]

I tried to start without the old "~/.mozilla" and nothing changes. I tried the 3.6a1pre binary distribution and the error does not show (I mean it does not hang). I have no gconf installed. I will look to find the 3.5 dev sources and try them.

Comment 11

[Marco Maggi]

The binary installation from:

firefox-3.5.2pre.en-US.linux-i686.tar.bz2

still hangs when opening the menu. But it does not print errors on the terminal.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

It would be great if you would have time to run the RC and beta builds of Firefox 3.5/3.1 which can be found here: http://releases.mozilla.org/pub/mozilla.org/firefox/releases/

Comment 13

[Marco Maggi]

I tried

http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.1b3/linux-i686/en-GB/firefox-3.1b3.tar.bz2

here is a summary, so far:

With NO GConf installed:

* Revision 3.0.11 always works, no problem.

* Revisions 3.5.1 and 3.5.2pre hang when opening a menu the
  first time.

* Revision 3.1b3 starts, displays the window, then crashes
  printing the following to the terminal:

/opt/firefox/3.1b3/crashreporter: error while loading shared libraries: libgconf-2.so.4: cannot open shared object file: No such file or directory

* Revision 3.6a1pre always works, no problem.

With GConf 2.26.2 and ORBit2 2.14.17
------------------------------------

Built  GConf from  source  (no Slackware  package) with  the
configure options:

--disable-gtk
--disable-defaults-service

it is my understanding that only 3.1b3 wants it, anyway...

* Revision 3.0.11 always works, no problem.

* Revision  3.1b3  starts,  displays  the  window  for  some
  second, then it crashes  and the crashreporter is not able
  to deliver  the report.   I cannot reproduce  it reliably,
  but  sometimes  (!?!)  it  prints  the  following  to  the
  terminal:

(crashreporter:27284): Gtk-CRITICAL **: gtk_widget_set_sensitive: assertion `GTK_IS_WIDGET (widget)' failed

(crashreporter:27284): Gtk-CRITICAL **: gtk_widget_set_sensitive: assertion `GTK_IS_WIDGET (widget)' failed

(crashreporter:27284): Gtk-CRITICAL **: gtk_widget_set_sensitive: assertion `GTK_IS_WIDGET (widget)' failed

** (crashreporter:27284): CRITICAL **: ORBit_demarshal_object: assertion `orb != CORBA_OBJECT_NIL' failed

* Revisions 3.5.1 and 3.5.2pre hang when opening a menu the
  first time.

* Revision 3.6a1pre always works, no problem.

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

What about beta 2 and beta 4? Do both crash too?

Comment 15

[Marco Maggi]

> What about beta 2 and beta 4? Do both crash too?

Which ones? If you mean the 3.1 series, I cannot find them at

http://releases.mozilla.org/pub/mozilla.org/firefox/releases

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Sorry that was the wrong link. Please check the builds at the following URL: ftp://ftp.mozilla.org/pub/firefox/releases/

Comment 17

[Marco Maggi]

A thing I had not noticed before: With revisions 3.0.*, when
the mouse enters  the tag of a menu in  the menubar, the tag
gets a raised border; with the other revisions this does not
happen.

* Revision 3.0.12 works fine.

* Revision 3.1b1 seems to work fine.

* Revision 3.1b2 seems to work fine.

* Revisions 3.5b4, 3.5b99,  3.5rc1, 3.5rc2, 3.5rc3 hang when
  I open a menu the first time.

Comment 18

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Marco, thanks for checking those builds. Given by your comment 13 it means that 3.1b3 is working for you? To narrow down the range it would be really helpful when you could run a regression test with nightly builds between the b2 and b3 release. Those builds can be found at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/

Comment 19

[Marco Maggi]

It sucks  plenty to  do a bisection  without a  page linking
existing builds.   And it  is even more  yuck to do  it over
archives without an increasing branch revision number.

Summary: 3.1b2 works fine, 3.1b3 crashes.

It is my understanding that:

* 3.1b2 was released 2008, Dec 01.
* 3.1b3 was released 2009, May 03.

With GConf installed, I found:

* Revision 3.1b3pre 2009, Jan 01 works fine.

* Revision 3.1b3pre  2009, Jan 11  hangs when I open  a menu
  the first time.  It does not crash.

* Revision 3.1b3pre  2009, Mar 02  hangs when I open  a menu
  the first time.  It does not crash.

* Revision 3.1b4pre 2009, Mar 07 crashes.

Comment 20

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #19)
> It sucks  plenty to  do a bisection  without a  page linking
> existing builds.   And it  is even more  yuck to do  it over
> archives without an increasing branch revision number.

What do you mean? All builds are linked from the page I have given in my last comment. The revision will not change but the build id. You can have a look at the Nightly Tester Tools add-on which gives access to it in the tools menu. It is a 14 digit number.

> * Revision 3.1b3pre 2009, Jan 01 works fine.
> 
> * Revision 3.1b3pre  2009, Jan 11  hangs when I open  a menu
>   the first time.  It does not crash.

That sounds good. We don't need the crash. More important is the hang. Can you please check between these two dates to get a timeframe of 1 day? That could help to identify a checkin.

Many thanks for your efforts. We are not too far away now.

Comment 21

[Marco Maggi]

(In reply to comment #20)
>(In reply to comment #19)
>> It sucks  plenty to  do a bisection  without a  page linking
>> existing builds.   And it  is even more  yuck to do  it over
>> archives without an increasing branch revision number.
>
> What do you mean? All builds are linked from the
> page I have given in my last comment. 
> [...]
> Can you please check between these two dates to get a
> timeframe of 1 day? 

Unless I was not able to find it, there is no single HTML page
linking all the existent 3.1b* builds available on the site.
There is not one of them for each day, so I have to scan:

ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/01/

by hand with "http://" or with a script for "lftp" with
"ftp://". Then all the archives for 3.1b3pre have the name:

firefox-3.1b3pre.en-US.linux-i686.tar.bz2

so I have to rename them when I save them on my system,
typing the date by hand. With names like:

firefox-3.1b3pre.2009-Jan-01.en-US.linux-i686.tar.bz2

or:

firefox-3.1b3pre.rev-1234.en-US.linux-i686.tar.bz2

renaming would not be needed.

When I unpack the archive I have to rename the top
directory from "firefox" to version+date, or create
a versioned directory and unpack the archive into it.

With archive names embedding ".rev-1234." one could store
all the archives directly in the same directory and one
could know right away how many change-sets there are
between two nightly builds.

Is there a way to know from the file names that two
consecutive nightly builds have actually been built
from different sources? Or do I have to search the
Mozilla site for the developers policy on handling
builds?

Comment 22

[Marco Maggi]

* Revision  3.1b3pre 2009, Jan  08 works  fine.  Mozilla/5.0
  (X11; U; Linux  i686; en-US; rv:1.9.1b3pre) Gecko/20090108
  Shiretoko/3.1b3pre ID:20090108020925

* Revision 3.1b3pre  2009, Jan 09  hangs when I open  a menu
  the first time.  It does not crash.

Comment 23

[Ria Klaassen (not reading all bugmail)]

Then it is likely that comment 1 is true.

Comment 24

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #23)
> Then it is likely that comment 1 is true.

Yes looks like. Marco, can you do one last check with the latest Minefield build? You can find it here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/07/2009-07-30-03-mozilla-central/

It should be fixed. Please report back. If that is the case we can mark this bug as dupe.

Comment 25

[Ria Klaassen (not reading all bugmail)]

Do you mean Bug 498089? That was Widget Win32, caused by bug 83056.
Then this bug is caused by Bug 419275. They have in common, that they similar but different OS and both belong to Bug 461963 -  [meta] System sounds / sound theme support.

Comment 26

[Marco Maggi]

I already stated in comment #13 that 3.6 always works. Anyway, yes the latest 3.6 works. Is there any hope for me to have a revision 3.5 working?

Comment 27

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Marco, can you attach gdb and get a stack trace of the hung Firefox?

Comment 28

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #26)
> I already stated in comment #13 that 3.6 always works. Anyway, yes the latest
> 3.6 works. Is there any hope for me to have a revision 3.5 working?

Doesn't it mean the issue has been already fixed on trunk but has not been backported to 3.5 yet? Would be interesting to know which patch on trunk fixed this hang.

Comment 30

[Karl Tomlinson (:karlt)]

(In reply to comment #13)
> /opt/firefox/3.1b3/crashreporter: error while loading shared libraries:
> libgconf-2.so.4: cannot open shared object file: No such file or directory

That's bug 434997.

> * Revision  3.1b3  starts,  displays  the  window  for  some
>   second, then it crashes  and the crashreporter is not able
>   to deliver  the report.   I cannot reproduce  it reliably,
>   but  sometimes  (!?!)  it  prints  the  following  to  the
>   terminal:

> ** (crashreporter:27284): CRITICAL **: ORBit_demarshal_object: assertion `orb
> != CORBA_OBJECT_NIL' failed

Bug 518244 (at least).

Workaround for now is to install libgnome-2.so.0 (unfortunately).

I simple way to get a stack on hang is to "kill -ABRT <pid>", send the crashreport and then check about:crashes.

Comment 31

[mmc]

I've produced a stack during the hang, I hope it helps:
http://crash-stats.mozilla.com/report/index/ff2fd406-df51-49a8-84bc-6ddf92090928?p=1

Comment 32

[Karl Tomlinson (:karlt)]

Thanks.  I wonder why esd_open_sound is making a dns query.
Is that a good reason to avoid esd?

Comment 33

[mmc]

Ok, I see that it's making a dns query (it always takes 3-5 seconds here). Still, why should it completely freeze the interface (even the throbber stops spinning)?
And I don't understand why we are trying to initialize the sounds anyway...

Comment 34

[Karl Tomlinson (:karlt)]

Here's the stack (iirc crash-stats.mozilla.com won't keep it forever).

0  	libc-2.9.so  	libc-2.9.so@0xc303d  	
1 	libresolv-2.9.so 	libresolv-2.9.so@0x878d 	
2 	libresolv-2.9.so 	libresolv-2.9.so@0x695e 	
3 	libresolv-2.9.so 	libresolv-2.9.so@0x700a 	
4 	libresolv-2.9.so 	libresolv-2.9.so@0x72dd 	
5 	libnss_dns-2.9.so 	libnss_dns-2.9.so@0x2932 	
6 	libc-2.9.so 	libc-2.9.so@0xa5a31 	
7 	libc-2.9.so 	libc-2.9.so@0xa7d79 	
8 	libesd.so.0.2.39 	libesd.so.0.2.39@0x3078 	
9 	libesd.so.0.2.39 	libesd.so.0.2.39@0x38b3 	
10 	libxul.so 	nsSound::Init 	widget/src/gtk2/nsSound.cpp:144
11 	libxul.so 	nsSound::PlaySystemSound 	widget/src/gtk2/nsSound.cpp:466
12 	libxul.so 	nsMenuPopupFrame::ShowPopup 	layout/xul/base/src/nsMenuPopupFrame.cpp:630
13 	libxul.so 	nsXULPopupManager::ShowPopupCallback 	layout/xul/base/src/nsXULPopupManager.cpp:578
14 	libxul.so 	nsXULPopupManager::FirePopupShowingEvent 	layout/xul/base/src/nsXULPopupManager.cpp:1047
15 	libxul.so 	nsXULPopupShowingEvent::Run 	layout/xul/base/src/nsXULPopupManager.cpp:2012
16 	libxul.so 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:510


(In reply to comment #33)
> And I don't understand why we are trying to initialize the sounds anyway...

Some systems play sounds when menus open.
But I think gtk-enable-event-sounds should be checked before initializing the sound system, and it looks like esd and canberra initialization could be separated so that esd is not even needed with gtk-enable-event-sounds.

Comment 35

[Michael Ventnor]

(In reply to comment #34)
> Some systems play sounds when menus open.
> But I think gtk-enable-event-sounds should be checked before initializing the
> sound system, and it looks like esd and canberra initialization could be
> separated so that esd is not even needed with gtk-enable-event-sounds.

I check gtk-enable-event-sounds every time because it might get changed while Firefox is running.
It seems to me that we don't need esd, or rather nsSound::Play on any platform anymore now that we have new Audio(). If it is still necessary, it might be worth exploring replacing esd with gstreamer.

Comment 36

[Michael Ventnor]

But to fix this bug, separating esd and libcanberra initialisation sounds good to me.

Comment 37

[Karl Tomlinson (:karlt)]

I'm not sure why this would be fixed for Marco in 3.6.
mmc, could you try a trunk or 3.6 build, please to see if you still have the problem there?

Comment 38

[Marco Maggi]

(In reply to comment #37)
> I'm not sure why this would be fixed for Marco in 3.6.
> mmc, could you try a trunk or 3.6 build, please to see if you still have the
> problem there?

Surprise! The following build hangs at every single menu opening, which,
I admit, is more consistent than the previous first-menu-only hanging.

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/09/2009-09-30-03-mozilla-1.9.2/firefox-3.6b1pre.en-US.linux-i686.tar.bz2

Just for the sake of sadomasochism, 3.7a1pre (30 Sept 2009) shows the
same behaviour.  Anyway, I confirm that 3.6a1pre-2009-Jul-30 works fine.

Comment 39

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to comment #35)
> It seems to me that we don't need esd, or rather nsSound::Play on any platform
> anymore now that we have new Audio().

nsSound::PlayEventSound and nsSound::PlaySystemSound are still needed, obviously. But yes, nsSound::Play playing Wave files could be rewritten to use libsydney_audio and some code exported from nsWaveDecoder.

Comment 40

[mmc]

(In reply to comment #37)

The same happens for the latest nightly:
http://crash-stats.mozilla.com/report/index/4061771d-143e-44ee-
a0f2-b37442091001?p=1

Comment 41

[mmc]

I don't understand why it wrapped this time... Anyway, the stack is the following:
0  	libc-2.9.so  	libc-2.9.so@0xc303d  	
1 	libresolv-2.9.so 	libresolv-2.9.so@0x878d 	
2 	libresolv-2.9.so 	libresolv-2.9.so@0x695e 	
3 	libresolv-2.9.so 	libresolv-2.9.so@0x700a 	
4 	libresolv-2.9.so 	libresolv-2.9.so@0x72dd 	
5 	libnss_dns-2.9.so 	libnss_dns-2.9.so@0x2932 	
6 	libc-2.9.so 	libc-2.9.so@0xa5a31 	
7 	libc-2.9.so 	libc-2.9.so@0xa7d79 	
8 	libesd.so.0.2.39 	libesd.so.0.2.39@0x3078 	
9 	libesd.so.0.2.39 	libesd.so.0.2.39@0x38b3 	
10 	libxul.so 	nsSound::Init 	widget/src/gtk2/nsSound.cpp:161
11 	libxul.so 	nsSound::PlayEventSound 	widget/src/gtk2/nsSound.cpp:444
12 	libxul.so 	nsMenuPopupFrame::ShowPopup 	layout/xul/base/src/nsMenuPopupFrame.cpp:642
13 	libxul.so 	nsXULPopupManager::ShowPopupCallback 	layout/xul/base/src/nsXULPopupManager.cpp:599
14 	libxul.so 	nsXULPopupManager::FirePopupShowingEvent 	layout/xul/base/src/nsXULPopupManager.cpp:1077
15 	libxul.so 	nsXULPopupShowingEvent::Run 	layout/xul/base/src/nsXULPopupManager.cpp:2050
16 	libxul.so 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:527
17 	libxul.so 	NS_ProcessNextEvent_P 	nsThreadUtils.cpp:230
18 	libxul.so 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:170
19 	libxul.so 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:182
20 	libxul.so 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3420
21 	firefox-bin 	main 	browser/app/nsBrowserApp.cpp:156
22 	libc-2.9.so 	libc-2.9.so@0x167a4

Comment 42

[Karl Tomlinson (:karlt)]

Thanks, mmc.

Marco:

The stack that mmc is reporting should only cause a hang once, so I suspect another issue is causing your hangs.  (mmc: tell me if I'm wrong)

Can you submit a crash report for the hang on second menu opening with the 3.7a1pre (30 Sept 2009) build (or another trunk build), please?  The crashreporter bugs should be fixed there.

Identify the process id with something like "ps -o pid,stime,args -u `whoami`"
and then "kill -ABRT <pid>".

Comment 43

[mmc]

(In reply to comment #42)
> The stack that mmc is reporting should only cause a hang once, so I suspect
> another issue is causing your hangs.  (mmc: tell me if I'm wrong)

yes, for me the hang happens only once.

Comment 44

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I filed bug 520417, it makes the sounds are played on another thread.

Comment 45

[Marco Maggi]

(In reply to comment #42)
> The stack that mmc is reporting should only cause a hang once, so I suspect
> another issue is causing your hangs.  (mmc: tell me if I'm wrong)
> 
> Can you submit a crash report for the hang on second menu opening with the
> 3.7a1pre (30 Sept 2009) build (or another trunk build), please?  The
> crashreporter bugs should be fixed there.

Did it, but I doubt it worked: I saw a message flashing "there was a problem reporting the crash", or something like that.

Comment 46

[Karl Tomlinson (:karlt)]

Thanks for trying, Marco.
"tail ~/.mozilla/firefox/Crash\ Reports/submit.log" may give a clue as to why it failed".

The other thing you can do with trunk builds is start Firefox again and view the url "about:crashes".  Even reports that have failed to send will be listed there (but, as far as I know, they don't look any different to other reports).  Clicking on a link to a report that hasn't sent successfully will try to send the report again.  A different method is used to send the report this time, which might succeed.

Comment 47

[Marco Maggi]

(In reply to comment #46)
> Thanks for trying, Marco.
> "tail ~/.mozilla/firefox/Crash\ Reports/submit.log" may give a clue as to why
> it failed".

The reason appears to be "couldn't resolve host name".

Comment 48

[Marco Maggi]

(In reply to comment #46)
> The other thing you can do with trunk builds is start Firefox again and view
> the url "about:crashes".  Even reports that have failed to send will be listed
> there (but, as far as I know, they don't look any different to other reports). 
> Clicking on a link to a report that hasn't sent successfully will try to send
> the report again.  A different method is used to send the report this time,
> which might succeed.

Did it, the report id is "0a6c6df2-e994-2ad1-1bc21a89-641f1055", submission time 04/10/09 07:20. There was no feedback on the page about success or failure...

Comment 49

[Karl Tomlinson (:karlt)]

Hmm.  I don't know what's happening.  Maybe it would be easiest to just email me 0a6c6df2-e994-2ad1-1bc21a89-641f1055.extra and 0a6c6df2-e994-2ad1-1bc21a89-641f1055.dmp from ~/.mozilla/firefox/Crash\ Reports/pending and I can submit from here.

Comment 50

[Marco Maggi]

(In reply to comment #49)
> Hmm.  I don't know what's happening.  Maybe it would be easiest to just email
> me 0a6c6df2-e994-2ad1-1bc21a89-641f1055.extra and
> 0a6c6df2-e994-2ad1-1bc21a89-641f1055.dmp from ~/.mozilla/firefox/Crash\
> Reports/pending and I can submit from here.

Done.

Comment 51

[Karl Tomlinson (:karlt)]

Thanks, Marco:

bp-611f9177-5af1-4815-8816-15ec72091004

In esd_open_sound, similar to mmc's hang but this time in libpthread:
0|0|libpthread-2.7.so||||0xc59e
0|1|libesd.so.0.2.38||||0x3f2d
0|2|libxul.so|nsSound::Init()|hg:hg.mozilla.org/mozilla-central:widget/src/gtk2/nsSound.cpp:7a75cd337fda|161|0xb
0|3|libxul.so|nsSound::PlayEventSound(unsigned int)|hg:hg.mozilla.org/mozilla-central:widget/src/gtk2/nsSound.cpp:7a75cd337fda|444|0x8
0|4|libxul.so|nsMenuPopupFrame::ShowPopup(int, int)|hg:hg.mozilla.org/mozilla-central:layout/xul/base/src/nsMenuPopupFrame.cpp:7a75cd337fda|642|0x9
0|5|libxul.so|nsXULPopupManager::ShowPopupCallback(nsIContent*, nsMenuPopupFrame*, int, int)|hg:hg.mozilla.org/mozilla-central:layout/xul/base/src/nsXULPopupManager.cpp:7a75cd337fda|599|0x10
0|6|libxul.so|nsXULPopupManager::FirePopupShowingEvent(nsIContent*, nsIContent*, nsPresContext*, nsPopupType, int, int)|hg:hg.mozilla.org/mozilla-central:layout/xul/base/src/nsXULPopupManager.cpp:7a75cd337fda|1077|0x14
0|7|libxul.so|nsXULPopupShowingEvent::Run()|hg:hg.mozilla.org/mozilla-central:layout/xul/base/src/nsXULPopupManager.cpp:7a75cd337fda|2050|0x16
0|8|libxul.so|nsThread::ProcessNextEvent(int, int*)|hg:hg.mozilla.org/mozilla-central:xpcom/threads/nsThread.cpp:7a75cd337fda|527|0xa
0|9|libxul.so|NS_ProcessNextEvent_P(nsIThread*, int)|nsThreadUtils.cpp|230|0xd

None of the stacks for other threads in libpthread have enough info to indicate what libesd might be doing, but it is clear that avoiding esd would solve the problem.

I had mis-assumed that nsSound was a singleton service, but in fact a new instance is created each time a sound is played.

elib is static, so elib is usually only dlopened once, but since bug 479929
was fixed a failure from esd_sound_open causes libesd to be dlclosed and dlopened (with an esd_open_sound) again for each subsequent nsSound instance.

It seems that this nsSound module was actually written to be a singleton
(either that or it was just written incorrectly): |elib| is static and opened
once (except as described above) but |esdref| is closed after the first
nsSound instance is destroyed.  So subsequent nsSound instances that use elib
are using an elib that has been |esd_close|d.

Comment 52

[Karl Tomlinson (:karlt)]

bug 469635 comment 29:

"I'm not sure why we call esd_open_sound anyway--the esdref we get back is never
used again (except to close ESD again), and the message about it being needed
for streams but not playing sounds is curious.

... we'll eventually call
esd_play_stream (which calls esd_open_sound internally)."

Comment 53

[Reed Loden [:reed]]

I hit something very similar to this all the time on trunk.

The first time I click any of the items on my bookmarks bar, it doesn't work (like I never clicked it). I have to click the item again for it to work.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091004 Minefield/3.7a1pre

Comment 54

[Karl Tomlinson (:karlt)]

(In reply to comment #53)
> The first time I click any of the items on my bookmarks bar, it doesn't work
> (like I never clicked it). I have to click the item again for it to work.

I expect that is likely different from this bug.  If that were this bug then I'd expect the action to work eventually (once the app became responsive again) without the need for another click.

Comment 55

[Karl Tomlinson (:karlt)]

BTW, nsISystemSound described in bug 520417 comment 3 would be enough to fix this bug because it would separate canberra and esd initialization.
(It looks like Masayuki is working on this.)

Comment 56

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

This should be fixed by bug 520417.

Now, esd initialization is dropped and the canberra initializing is automatically executed after immediately the application start-up process is finished. But it's executed on the main thread, if the hang up is still there at start-up, please file a new bug and cc me.

Comment 57

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

bug 520417 is backed out.

Comment 58

[Karl Tomlinson (:karlt)]

I don't understand why this was changed from status 1.9.1 wanted to wontfix.
Separating canberra and esd initialization in the existing nsSound should be a simple change for 1.9.1 and 1.9.2 branches.

Comment 59

[Joe Drew (not getting mail)]

Karl &/or Masayuki: what's the status on this bug? We have until Wednesday to fix it.

Comment 60

[Karl Tomlinson (:karlt)]

Bug 520417 is not destined for 1.9.2.
I think we could do a small fix here, but that could happen in a dot release.
Would be nice to fix this, but it's not a regression from 1.9.1, so no need to hold up 1.9.2 for it, really.

Comment 61

[Joe Drew (not getting mail)]

I agree! Let's call this not blocking, then.

Comment 62

[Marco Maggi]

Sorry for waking up this again, I get it with FF 3.6 today's release. I still have the system configuration/software I outlined in a previous message. The problem is a bit different though: when I click on a menu, FF hangs for a while and when it wakes up no menu is displayed. For what I tested so far, it happens every time I click on a menu.

Comment 64

[Wayne Mery (:wsmwk)]

Is this problem gone for you in newer version?

Comment 65

[Marco Maggi]

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #64)
> Is this problem gone for you in newer version?

If the question was addressed to me: the problem has been fixed for some time.  Thanks.

Comment 66

[Matthew Cline]

Why is a "needinfo" flag being set for me?  As far as I can tell, I'm merely on the CC list.

Comment 67

[Wayne Mery (:wsmwk)]

(In reply to Matthew Cline from comment #66)
> Why is a "needinfo" flag being set for me?  As far as I can tell, I'm merely
> on the CC list.

because the your bug 509372 was duped to this bug :)
But perhaps you no longer have the problem described in bug 509372?

Comment 68

[Wayne Mery (:wsmwk)]

(In reply to Marco Maggi from comment #65)
> (In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment
> #64)
> > Is this problem gone for you in newer version?
> 
> If the question was addressed to me: the problem has been fixed for some
> time.  Thanks.

Hmm. But bug 520417 and bug 683184 are still open :(   So I guess this one too

Comment 69

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Does somebody still see a hang at first sound play on Linux?

Currently, we've already made nsSound for Windows play sounds in a player thread (bug 1363163). So, if we can make nsSound for GTK do same thing, we can fix this bug simply. However, I don't know if it's still necessary.

Comment 70

[Andrei Purice]

Hey Wayne,
Can you still reproduce this issue or should we close it?

Comment 71

[Wayne Mery (:wsmwk)]

I don't run linux, so I'm not a great person to ask

Comment 72

[Martin Stránský [:stransky] (ni? me)]

Okay, let's close this one.