Would it be possible to try the Firefox 102 binary from Mozilla (you can get it from https://www.mozilla.org/en-US/firefox/all/#product-desktop-esr) and see whether it's fixed there or not (we are currently working on bringing the Firefox 102 to RHEL so would be good if 102 fixes your problem).

Tomas,

Yes indeed. I downloaded the 102 .tar.bz2 file from the URL you gave, decompressed it to a directory called firefox in user2's space, made sure everything in it was owned by user2, and ran

./firefox/firefox &

as user2. Sadly exactly the same problem occurred; as before it remains the same with selinux permissive.

Thank you for the suggestion though.

Roger Sewell.

Caveat to the above: The tarball from Mozilla's website containing firefox 102 contains no installation instructions and no rpm and no ReadMe file. So please understand that all I did is exactly what I said above - and I can't be sure that e.g. no libraries from the pre-existing previous installation were invoked.

I tried that on VM and I can't reproduce. Please attach your about:support page.

In case you're use HW acceleration try to turn it off:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Check_WebRender_state_(Hardware_acceleration)

The 'window asking whether you want to force-quit' means there's a deadlock and Firefox does not proceed system events. We need to know where is Firefox frozen.

Please install Firefox debug info packages and attach gdb to it when it's frozen:
https://fedoraproject.org/wiki/Debugging_guidelines_for_Mozilla_products#Attach_debugger_to_running_application

and attach a backtrace from gdb.

Thanks.

Created attachment 1906261 [details]
Various requested items

The README file in the attached tarball details what I did in response to your requests; the various outputs requested are also in the tarball. Please note that, as therein explained, not everything you asked for worked, probably precisely because of this bug.

Many thanks for your help.

Thanks, the backtrace is here:

#1  0x00007fe3a0c7f087 in nanosleep () from /lib64/libc.so.6
No symbol table info available.
#2  0x00007fe37efe11c7 in pa_msleep () from /lib64/libpulse.so.0
No symbol table info available.
#3  0x00007fe37ef51cbc in pa_get_runtime_dir () from /usr/lib64/pulseaudio/libpulsecommon-15.0.so
No symbol table info available.
#4  0x00007fe37ef51f3a in get_path () from /usr/lib64/pulseaudio/libpulsecommon-15.0.so
No symbol table info available.
#5  0x00007fe37efc15af in pa_context_connect () from /lib64/libpulse.so.0
No symbol table info available.
#6  0x00007fe376813b6b in context_connect () from /usr/lib64/libcanberra-0.30/libcanberra-pulse.so
No symbol table info available.
#7  0x00007fe376814238 in pulse_driver_open () from /usr/lib64/libcanberra-0.30/libcanberra-pulse.so
No symbol table info available.
#8  0x00007fe38565a749 in context_open_unlocked () from /lib64/libcanberra.so.0
No symbol table info available.
#9  0x00007fe38565b122 in ca_context_play_full () from /lib64/libcanberra.so.0
No symbol table info available.
#10 0x00007fe38565b5d9 in ca_context_play () from /lib64/libcanberra.so.0
No symbol table info available.
#11 0x00007fe3963eb95b in nsSound::PlayEventSound (this=<optimized out>, aEventId=6) at /usr/src/debug/firefox-91.12.0-2.el9_0.x86_64/widget/gtk/nsSound.cpp:385
        settings = 0x7fe385531fe0
        ctx = <optimized out>
        settings = <optimized out>
        ctx = <optimized out>
        enable_sounds = <optimized out>
#12 nsSound::PlayEventSound (this=<optimized out>, aEventId=6) at /usr/src/debug/firefox-91.12.0-2.el9_0.x86_64/widget/gtk/nsSound.cpp:357
        settings = <optimized out>
        ctx = <optimized out>
        enable_sounds = <optimized out>
#13 0x00007fe3967df30d in nsMenuPopupFrame::ShowPopup (this=0x7fe377e7d870, aIsContextMenu=<optimized out>) at /usr/src/debug/firefox-91.12.0-2.el9_0.x86_64/layout/xul/nsMenuPopupFrame.cpp:989
        sound = {<nsCOMPtr_base> = {mRawPtr = 0x7fe369ca1e80}, <No data fields>}
        menuFrame = <optimized out>

which looks like https://bugzilla.redhat.com/show_bug.cgi?id=568178

I think it's related to your two user scenario here.

As a workaround you may disable system sounds.

As it freezes in pulseaudio changing the component.

Btw. can you install debuginfo for pulseaudio (for /usr/lib64/pulseaudio/libpulsecommon-15.0.so) and attach the bactrace again?
Thanks.

Martin, 

Thank you very much - I have now solved it (or at least am well on the way to) as a result of your comments. Ironically, the most helpful one was just saying that you weren't able to reproduce it, which got me thinking more on the right lines. 

I copied user2's account then deleted all the .[^.]* files in it, and let the system repopulate them on user2's next login. That leaves user2 with work to do to get his account set up right, but it made the scenario I reported go back to working properly.

I will let you know when I've found the exact file that was responsible (probably tomorrow sometime). The root cause is lazy migration (by me) of user2's account from 8.6 to 9.0 by just copying all the files instead of setting them all up from scratch. So NOTABUG as far as I can see.

Your help was much appreciated. If you would still like the pulseaudio backtrace please say (obviously with the version of user2's account that was present when the "bug" was evident). Otherwise please consider this closed. Many thanks !

Yours, Roger Sewell.

Created attachment 1906501 [details]
Files that cause the bug to be reproduced

First, I was wrong as to the root cause being careless migration - see below.

Second, when the bug is present, the listing of user2's ~/.pulse directory looks like this (user2 being rfsnet):

  drwx------.  2 rfsnet rfsnet  4096 Aug 14 11:44 .
  drwxrwxr-x. 31 rfsnet rfsnet  4096 Aug 18 21:52 ..
  lrwxrwxrwx.  1 rfsnet rfsnet    23 Aug  1 13:53 48d8a0c1b7554effb9303ff6ee9e0e84-runtime -> /tmp/pulse-Q0hk23NIb7HV
  lrwxrwxrwx.  1 rfsnet rfsnet    23 Aug 14 11:44 48d8a0c1b7554effb9303ff6ee9e0e84-runtime.tmp -> /tmp/pulse-T86EfUVPSyvz
  -rw-r--r--.  1 rfsnet rfsnet 24576 Jan 13  2021 820b143de7cc4bf4864cd49f8053c153-card-database.tdb
  -rw-r--r--.  1 rfsnet rfsnet     1 Jan 13  2021 820b143de7cc4bf4864cd49f8053c153-default-sink
  -rw-r--r--.  1 rfsnet rfsnet     1 Jan 13  2021 820b143de7cc4bf4864cd49f8053c153-default-source
  -rw-r--r--.  1 rfsnet rfsnet  8192 Apr  8  2020 820b143de7cc4bf4864cd49f8053c153-device-volumes.tdb
  lrwxrwxrwx.  1 rfsnet rfsnet    23 Jan 13  2021 820b143de7cc4bf4864cd49f8053c153-runtime -> /tmp/pulse-zgfReFfE8mnM
  -rw-r--r--.  1 rfsnet rfsnet 12288 Apr  8  2020 820b143de7cc4bf4864cd49f8053c153-stream-volumes.tdb

Removal of the file 

48d8a0c1b7554effb9303ff6ee9e0e84-runtime.tmp -> /tmp/pulse-T86EfUVPSyvz 

which points to an existing empty directory, solves the problem.

Moreover, deleting the contents of user2's ~/.pulse directory and replacing it by putting the attached tarball in user2's home directory and doing

cd ~rfsnet
tar -xzf bad.pulse.tar.gz

brings the problem back again - not just in the two user scenario, but also when logged in on the display as rfsnet.

Moreover the date on the file 48d8a0c1b7554effb9303ff6ee9e0e84-runtime.tmp and on the directory it points to are two weeks later than migration time, so the file has been written by the system, not just migrated from 8.6 .

However all my attempts to get the system to produce such a file have failed.

You suggested that this bug might have similarities to bug 568178 on Fedora from 2010; it might, but I'd guess it might have more to do with the change to pipewire in 9.0, and be related to bug 2114896 .

In any event thank you for your help which has been fantastic. I'm clearing the needinfo flag for now as I'm guessing that given the above you no longer need it, but if you or one of your colleagues would still like a further backtrace with the pulseaudio debug info present, I'll be more than happy to provide it.

Yours, Roger.

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.