Closed Bug 1736770 Opened 3 years ago Closed 3 years ago

Firefox 93 freezes when visiting some pages

Categories

(Core :: Widget: Gtk, defect)

Product:
Core
Component:
Widget: Gtk
Version:
Firefox 93
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1735905

People

(Reporter: jirislaby, Unassigned)

References

Details

Attachments

(1 file)

gdb's "thread apply all bt" of the main process
40.61 KB, application/octet-stream
Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:93.0) Gecko/20100101 Firefox/93.0

Steps to reproduce:

Every time I go to my internet banking calendar (you cannot obviously visit it):
https://online.mbank.cz/cs/Login#calendar/calendar
whole FF freezes. Actually, for a few seconds, I still can open a new tab and go to google.cz for example. But loading never finishes and the window is marked as "not responding" by window manager.

This happens in the safe mode too. I don't think this was a problem with 92 (but I'm not sure).

I can provide traces from gdb, but there are 6 ff processes for this single page with 10+ threads each, so you have to advise me of which one.

More info: this is openSUSE Tumbleweed and its ff 93 package:
$ rpm -q MozillaFirefox
MozillaFirefox-93.0-1.1.x86_64

There is even a zombie (Socket Process) not reaped by the main process:

xslaby 11949 4.9 2.9 3145908 473396 pts/18 Sl 07:45 0:36 /usr/lib64/firefox/firefox
xslaby 12028 2.3 1.6 2694160 266848 pts/18 Sl 07:45 0:17 _ /usr/lib64/firefox/firefox -contentproc -childID 1 -isForBrowser -prefsLen 1 -prefMapSize 259217 -safeMode -parentBuildID 20210927210923 -appdir /usr/lib64/firefox/browser 11949 true tab
xslaby 12066 0.2 0.7 2449300 116072 pts/18 Sl 07:45 0:02 _ /usr/lib64/firefox/firefox -contentproc -childID 2 -isForBrowser -prefsLen 4789 -prefMapSize 259217 -safeMode -parentBuildID 20210927210923 -appdir /usr/lib64/firefox/browser 11949 true tab
xslaby 12092 0.0 0.2 200868 44052 pts/18 Sl 07:45 0:00 _ /usr/lib/mozilla/kmozillahelper
xslaby 12117 0.1 0.6 2434712 112024 pts/18 Sl 07:45 0:01 _ /usr/lib64/firefox/firefox -contentproc -childID 3 -isForBrowser -prefsLen 5488 -prefMapSize 259217 -safeMode -parentBuildID 20210927210923 -appdir /usr/lib64/firefox/browser 11949 true tab
xslaby 12161 0.0 0.0 0 0 pts/18 Z 07:46 0:00 _ [Socket Process] <defunct>
xslaby 12187 0.0 0.2 188728 42100 pts/18 Sl 07:46 0:00 _ /usr/lib64/firefox/firefox -contentproc -parentBuildID 20210927210923 -prefsLen 5826 -prefMapSize 259217 -appdir /usr/lib64/firefox/browser 11949 true rdd
xslaby 12207 0.1 0.6 2420836 110768 pts/18 Sl 07:47 0:00 _ /usr/lib64/firefox/firefox -contentproc -childID 4 -isForBrowser -prefsLen 5826 -prefMapSize 259217 -safeMode -parentBuildID 20210927210923 -appdir /usr/lib64/firefox/browser 11949 true tab

Hmm, there are many threads waiting for a mutex:
mozilla::detail::ConditionVariableImpl::wait(mozilla::detail::MutexImpl&)

Is this a deadlock?

There is also an interesting downstream bug:
https://bugzilla.suse.com/show_bug.cgi?id=1190141

It's likely related to reading the fips file:

Check for system-wide FIPS mode is required and /proc/sys/crypto/fips_enabled cannot be opened for reading - aborting
Redirecting call to abort() to mozalloc_abort

I can see the Socket Process crashing too:

$ dmesg|grep -A1 Socket
[103545.585596] Socket Process[25493]: segfault at 0 ip 000055d70ea407ae sp 00007fff321dd980 error 6 in firefox[55d70ea32000+79000]
[103545.585606] Code: 20 68 08 00 48 8b 33 e8 20 1d ff ff 48 8b 33 bf 0a 00 00 00 e8 e3 1d ff ff 48 8d 05 dc 88 08 00 48 8d 15 33 b0 06 00 48 89 10 <c7> 04 25 00 00 00 00 00 00 00 00 0f 0b 0f 1f 44 00 00 48 85 ff 74

[104023.071768] Socket Process[2779]: segfault at 0 ip 000055cc28f737ae sp 00007ffe09c3e720 error 6 in firefox[55cc28f65000+79000]
[104023.071790] Code: 20 68 08 00 48 8b 33 e8 20 1d ff ff 48 8b 33 bf 0a 00 00 00 e8 e3 1d ff ff 48 8d 05 dc 88 08 00 48 8d 15 33 b0 06 00 48 89 10 <c7> 04 25 00 00 00 00 00 00 00 00 0f 0b 0f 1f 44 00 00 48 85 ff 74

[107711.736353] Socket Process[12161]: segfault at 0 ip 000056546710d7ae sp 00007ffeead3df30 error 6 in firefox[5654670ff000+79000]
[107711.736368] Code: 20 68 08 00 48 8b 33 e8 20 1d ff ff 48 8b 33 bf 0a 00 00 00 e8 e3 1d ff ff 48 8d 05 dc 88 08 00 48 8d 15 33 b0 06 00 48 89 10 <c7> 04 25 00 00 00 00 00 00 00 00 0f 0b 0f 1f 44 00 00 48 85 ff 74
[107894.617959] Socket Process[3600]: segfault at 0 ip 000055a064df47ae sp 00007fffc5b13e20 error 6 in firefox[55a064de6000+79000]
[107894.617993] Code: 20 68 08 00 48 8b 33 e8 20 1d ff ff 48 8b 33 bf 0a 00 00 00 e8 e3 1d ff ff 48 8d 05 dc 88 08 00 48 8d 15 33 b0 06 00 48 89 10 <c7> 04 25 00 00 00 00 00 00 00 00 0f 0b 0f 1f 44 00 00 48 85 ff 74

I can reproduce the issue on OpenSUSE Tumbleweed. Downgrading to Firefox 92 does not solve the problem.

Other sites I've managed to reproduce this on (no login required):
https://secure07c.chase.com/web/auth/dashboard
https://us.etrade.com/e/t/user/login

Backtrace:

#0 0x000055c9ddd367ae in mozalloc_abort ()
#1 0x000055c9ddd28dcd in ()
#2 0x00007f43e11afb21 in fatal (fmt=fmt@entry=0x7f43e11f00e8 "Check for system-wide FIPS mode is required and %s cannot be opened for reading - aborting")
at ../freebl/fips-selftest.inc:76
#3 0x00007f43e11aff14 in fips_isWantedProc () at ../freebl/fips-selftest.inc:102
#4 fips_isWanted () at ../freebl/fips-selftest.inc:153
#5 fips_initTest
(libName=libName@entry=0x7f43e11efd27 "softokn", addr=addr@entry=0x7f43e11afa20 <fips_initTestSoftoken>, cryptoCheck=cryptoCheck@entry=0x7f43e11dfe30 <fips_checkCryptoSoftoken>) at ../freebl/fips-selftest.inc:290
#6 0x00007f43e11afa3e in fips_initTestSoftoken () at /usr/src/debug/mozilla-nss-3.70-1.1.x86_64/nss/lib/softoken/fips.c:26
#7 0x00007f43ece8972e in call_init (env=0x7f43ec622000, argv=0x7fff345ceb68, argc=13, l=<optimized out>) at dl-init.c:70
#8 call_init (l=<optimized out>, argc=13, argv=0x7fff345ceb68, env=0x7f43ec622000) at dl-init.c:26
#9 0x00007f43ece8981c in _dl_init (main_map=0x7f43ec67c000, argc=13, argv=0x7fff345ceb68, env=0x7f43ec622000) at dl-init.c:117
#10 0x00007f43ecb56905 in __GI__dl_catch_exception
(exception=exception@entry=0x0, operate=operate@entry=0x7f43ece8d390 <call_dl_init>, args=args@entry=0x7fff345cd3f0)
at /usr/src/debug/glibc-2.34-2.1.x86_64/elf/dl-error-skeleton.c:182
#11 0x00007f43ece8deea in dl_open_worker (a=a@entry=0x7fff345cd5a0) at dl-open.c:788
#12 0x00007f43ecb568a8 in __GI__dl_catch_exception
(exception=exception@entry=0x7fff345cd580, operate=operate@entry=0x7f43ece8daa0 <dl_open_worker>, args=args@entry=0x7fff345cd5a0)
at /usr/src/debug/glibc-2.34-2.1.x86_64/elf/dl-error-skeleton.c:208
#13 0x00007f43ece8d6bf in _dl_open
(file=0x7fff345cd580 "pace updatedir='' updateCertPref", mode=-2147483646, caller_dlopen=0x7f43ec9d28eb <PR_LoadLibraryWithFlags+203>, nsid=-2, argc=13, argv=0x7fff345ceb68, env=0x7f43ec622000) at dl-open.c:863
#14 0x00007f43eca85d8c in dlopen_doit (a=a@entry=0x7fff345cd810) at dlopen.c:56
#15 0x00007f43ecb568a8 in __GI__dl_catch_exception (exception=exception@entry=0x7fff345cd770, operate=0x7f43eca85d30 <dlopen_doit>, args=0x7fff345cd810)
at /usr/src/debug/glibc-2.34-2.1.x86_64/elf/dl-error-skeleton.c:208
#16 0x00007f43ecb56973 in __GI__dl_catch_error
(objname=0x7fff345cd7c8, errstring=0x7fff345cd7d0, mallocedp=0x7fff345cd7c7, operate=<optimized out>, args=<optimized out>)
at /usr/src/debug/glibc-2.34-2.1.x86_64/elf/dl-error-skeleton.c:227
#17 0x00007f43eca8588e in _dlerror_run (operate=operate@entry=0x7f43eca85d30 <dlopen_doit>, args=args@entry=0x7fff345cd810) at dlerror.c:138
#18 0x00007f43eca85e18 in dlopen_implementation (dl_caller=<optimized out>, mode=<optimized out>, file=0x7f43e1256600 "/lib64/libsoftokn3.so") at dlopen.c:71
#19 ___dlopen (file=file@entry=0x7f43e1256600 "/lib64/libsoftokn3.so", mode=<optimized out>) at dlopen.c:81
#20 0x00007f43ec9d28eb in pr_LoadLibraryByPathname (flags=26, name=0x7f43e1256600 "/lib64/libsoftokn3.so") at linking/prlink.c:584
#21 PR_LoadLibraryWithFlags (libSpec=..., flags=flags@entry=26) at linking/prlink.c:386
#22 0x00007f43e14d09ac in loader_LoadLibInReferenceDir
(referencePath=referencePath@entry=0x7f43e12565c0 "/lib64/libnss3.so", name=name@entry=0x7f43e15ed440 "libsoftokn3.so")
at /usr/src/debug/mozilla-nss-3.70-1.1.x86_64/nss/lib/util/secload.c:85
#23 0x00007f43e14d0a19 in PORT_LoadLibraryFromOrigin
(existingShLibName=existingShLibName@entry=0x7f43e15ed44f "libnss3.so", staticShLibFunc=staticShLibFunc@entry=0x7f43e153d670 <softoken_LoadDSO>, newShLibName=newShLibName@entry=0x7f43e15ed440 "libsoftokn3.so") at /usr/src/debug/mozilla-nss-3.70-1.1.x86_64/nss/lib/util/secload.c:151
#24 0x00007f43e153d68e in softoken_LoadDSO () at ../pk11wrap/pk11load.c:373
#25 0x00007f43ec9de372 in PR_CallOnce (func=0x7f43e153d670 <softoken_LoadDSO>, once=0x7f43e1621248 <loadSoftokenOnce.lto_priv.0>) at misc/prinit.c:780
#26 PR_CallOnce (once=once@entry=0x7f43e1621248 <loadSoftokenOnce.lto_priv.0>, func=func@entry=0x7f43e153d670 <softoken_LoadDSO>) at misc/prinit.c:766
#27 0x00007f43e1545293 in secmod_LoadPKCS11Module (mod=mod@entry=0x7f43ec6a5420, oldModule=oldModule@entry=0x7fff345cda98) at ../pk11wrap/pk11load.c:424
#28 0x00007f43e154ab7d in SECMOD_LoadModule
(modulespec=0x7f43e1239740 "name="NSS Internal Module" parameters="configdir='' certPrefix='' keyPrefix='' secmod='' flags=readOnly,noCertDB,noModDB,forceOpen,optimizeSpace updatedir='' updateCertPrefix='' updateKeyPrefix='' upd"..., parent=0x0, recurse=1) at ../pk11wrap/pk11pars.c:1946
#29 0x00007f43e15122a7 in nss_InitModules
(configdir=configdir@entry=0x7f43e15e6153 "", certPrefix=certPrefix@entry=0x7f43e15e6153 "", keyPrefix=keyPrefix@entry=0x7f43e15e6153 "", secmodName=secmodName@entry=0x7f43e15e6153 "", updateDir=updateDir@entry=0x7f43e15e6153 "", updCertPrefix=updCertPrefix@entry=0x7f43e15e6153 "", updKeyPrefix=<optimized out>, updateID=<optimized out>, updateName=<optimized out>, configName=<optimized out>, configStrings=<optimized out>, pwRequired=<optimized out>, readOnly=<optimized out>, noCertDB=<optimized out>, noModDB=<optimized out>, forceOpen=<optimized out>, optimizeSpace=<optimized out>, isContextInit=<optimized out>)
at /usr/src/debug/mozilla-nss-3.70-1.1.x86_64/nss/lib/nss/nssinit.c:464
#30 0x00007f43e1512771 in nss_Init
(configdir=configdir@entry=0x7f43e15e6153 "", certPrefix=certPrefix@entry=0x7f43e15e6153 "", keyPrefix=keyPrefix@entry=0x7f43e15e6153 "", secmodName=secmodName@entry=0x7f43e15e6153 "", updateDir=updateDir@entry=0x7f43e15e6153 "", updCertPrefix=updCertPrefix@entry=0x7f43e15e6153 "", updKeyPrefix=0x7f43e15e6153 "", updateID=0x7f43e15e6153 "", updateName=0x7f43e15e6153 "", initContextPtr=0x0, initParams=0x0, readOnly=1, noCertDB=1, noModDB=1, forceOpen=1, noRootInit=1, optimizeSpace=1, noSingleThreadedModules=0, allowAlreadyInitializedModules=0, dontFinalizeModules=0)
at /usr/src/debug/mozilla-nss-3.70-1.1.x86_64/nss/lib/nss/nssinit.c:689
#31 0x00007f43e1516ec8 in NSS_NoDB_Init (configdir=<optimized out>) at /usr/src/debug/mozilla-nss-3.70-1.1.x86_64/nss/lib/nss/nssinit.c:950

The crash is happening inside a load-time constructor for /lib64/libsoftokn3.so, which was upgraded from 3.69 to 3.70 at the same time as Firefox 92 was upgraded to 93.

DIsassembly proves that it tried to open /proc/sys/crypto/fips_enabled and aborted execution after that failed. That proc node exists and is readable.

Sandbox problem. Strace shows this:

[pid 338967] openat(AT_FDCWD, "/proc/sys/crypto/fips_enabled", O_RDONLY) = 257
[pid 338967] --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_errno=EBUSY, si_call_addr=0x7fd65f9e5604, si_syscall=__NR_openat, si_arch=AUDIT_ARCH_X86_64} ---
[pid 338967] openat(AT_FDCWD, "/lib64/libsoftokn3.so", O_RDONLY|O_CLOEXEC) = 257
[pid 338967] --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_errno=EBUSY, si_call_addr=0x7fd65fd817f8, si_syscall=__NR_openat, si_arch=AUDIT_ARCH_X86_64} ---
[pid 338971] openat(AT_FDCWD, "/lib64/libsoftokn3.so", O_RDONLY|O_NOCTTY|O_CLOEXEC) = 178
[pid 338967] --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_errno=EXDEV, si_call_addr=0x7fd65fd815be, si_syscall=__NR_newfstatat, si_arch=AUDIT_ARCH_X86_64} ---
[pid 338967] openat(AT_FDCWD, "/usr/lib64/firefox/libsqlite3.so.0", O_RDONLY|O_CLOEXEC) = 257
[pid 338967] --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_errno=EBUSY, si_call_addr=0x7fd65fd817f8, si_syscall=__NR_openat, si_arch=AUDIT_ARCH_X86_64} ---
[pid 338971] openat(AT_FDCWD, "/usr/lib64/firefox/libsqlite3.so.0", O_RDONLY|O_NOCTTY|O_CLOEXEC) = -1 ENOENT (Arquivo ou diretório inexistente)
[pid 338967] openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 257
[pid 338967] --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_errno=EBUSY, si_call_addr=0x7fd65fd817f8, si_syscall=__NR_openat, si_arch=AUDIT_ARCH_X86_64} ---
[pid 338971] openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_NOCTTY|O_CLOEXEC) = 178
[pid 338967] --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_errno=EXDEV, si_call_addr=0x7fd65fd815be, si_syscall=__NR_newfstatat, si_arch=AUDIT_ARCH_X86_64} ---
[pid 338967] openat(AT_FDCWD, "/lib64/libsqlite3.so.0", O_RDONLY|O_CLOEXEC) = 257
[pid 338967] --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_errno=EBUSY, si_call_addr=0x7fd65fd817f8, si_syscall=__NR_openat, si_arch=AUDIT_ARCH_X86_64} ---
[pid 338971] openat(AT_FDCWD, "/lib64/libsqlite3.so.0", O_RDONLY|O_NOCTTY|O_CLOEXEC) = 178
[pid 338967] --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_errno=EXDEV, si_call_addr=0x7fd65fd815be, si_syscall=__NR_newfstatat, si_arch=AUDIT_ARCH_X86_64} ---
[pid 338967] --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_errno=EXDEV, si_call_addr=0x7fd65f9e4d9e, si_syscall=__NR_newfstatat, si_arch=AUDIT_ARCH_X86_64} ---
[pid 338967] openat(AT_FDCWD, "/proc/sys/crypto/fips_enabled", O_RDONLY) = 257
[pid 338967] --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_errno=EBUSY, si_call_addr=0x7fd65f9e5604, si_syscall=__NR_openat, si_arch=AUDIT_ARCH_X86_64} ---
[pid 338967] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---

Workaround: LD_PRELOAD=/lib64/libsoftokn3.so firefox

Downgrading libsoftokn3 didn't help

Note the fips issue is fixed in openSUSE:Factory/MozillaFirefox and will reach Tumbleweed soon:
https://build.opensuse.org/package/view_file/openSUSE:Factory/MozillaFirefox/mozilla-sandbox-fips.patch?expand=1

I think the issue can be closed as fixed.

Thanks Martin

The workaround worked for the two sites above, but not my bank. Going to it loads a page, but then Firefox freezes all tabs. No crashes are reported, though. I did see some more SIGSYS when tracing a clean profile so I'm hoping your patch fixes it. Will report soon.

(In reply to Martin Liška from comment #7)

I think the issue can be closed as fixed.

Wait, why? Is the Sandbox something that Tumbleweed created? Because if it comes from Firefox and NSS comes from Mozilla, the problem probably exists upstream elsewhere too.

MozillaFirefox-93.0-2.2 from Tumbleweed still has the issue. Same backtrace:

#0 0x0000564d591567ae in mozalloc_abort ()
#1 0x0000564d59148dcd in ()
#2 0x00007fc1dc12db21 in fatal (fmt=fmt@entry=0x7fc1dc16e0e8 "Check for system-wide FIPS mode is required and %s cannot be opened for reading - aborting")
at ../freebl/fips-selftest.inc:76
#3 0x00007fc1dc12df14 in fips_isWantedProc () at ../freebl/fips-selftest.inc:102
#4 fips_isWanted () at ../freebl/fips-selftest.inc:153
#5 fips_initTest
(libName=libName@entry=0x7fc1dc16dd27 "softokn", addr=addr@entry=0x7fc1dc12da20 <fips_initTestSoftoken>, cryptoCheck=cryptoCheck@entry=0x7fc1dc15de30 <fips_checkCryptoSoftoken>) at ../freebl/fips-selftest.inc:290
#6 0x00007fc1dc12da3e in fips_initTestSoftoken () at /usr/src/debug/mozilla-nss-3.70-1.1.x86_64/nss/lib/softoken/fips.c:26
#7 0x00007fc1e7dfe72e in call_init (env=0x7fc1e7622800, argv=0x7ffcf694d708, argc=13, l=<optimized out>) at dl-init.c:70
#8 call_init (l=<optimized out>, argc=13, argv=0x7ffcf694d708, env=0x7fc1e7622800) at dl-init.c:26
#9 0x00007fc1e7dfe81c in _dl_init (main_map=0x7fc1e767b800, argc=13, argv=0x7ffcf694d708, env=0x7fc1e7622800) at dl-init.c:117
#10 0x00007fc1e7acb905 in __GI__dl_catch_exception
(exception=exception@entry=0x0, operate=operate@entry=0x7fc1e7e02390 <call_dl_init>, args=args@entry=0x7ffcf694bf90)
at /usr/src/debug/glibc-2.34-2.1.x86_64/elf/dl-error-skeleton.c:182
#11 0x00007fc1e7e02eea in dl_open_worker (a=a@entry=0x7ffcf694c140) at dl-open.c:788
#12 0x00007fc1e7acb8a8 in __GI__dl_catch_exception
(exception=exception@entry=0x7ffcf694c120, operate=operate@entry=0x7fc1e7e02aa0 <dl_open_worker>, args=args@entry=0x7ffcf694c140)
at /usr/src/debug/glibc-2.34-2.1.x86_64/elf/dl-error-skeleton.c:208
#13 0x00007fc1e7e026bf in _dl_open
(file=0x7ffcf694c120 "", mode=-2147483646, caller_dlopen=0x7fc1e79478eb <PR_LoadLibraryWithFlags+203>, nsid=-2, argc=13, argv=0x7ffcf694d708, env=0x7fc1e7622800) at dl-open.c:863
#14 0x00007fc1e79fad8c in dlopen_doit (a=a@entry=0x7ffcf694c3b0) at dlopen.c:56
#15 0x00007fc1e7acb8a8 in __GI__dl_catch_exception (exception=exception@entry=0x7ffcf694c310, operate=0x7fc1e79fad30 <dlopen_doit>, args=0x7ffcf694c3b0)
at /usr/src/debug/glibc-2.34-2.1.x86_64/elf/dl-error-skeleton.c:208
#16 0x00007fc1e7acb973 in __GI__dl_catch_error
(objname=0x7ffcf694c368, errstring=0x7ffcf694c370, mallocedp=0x7ffcf694c367, operate=<optimized out>, args=<optimized out>)
at /usr/src/debug/glibc-2.34-2.1.x86_64/elf/dl-error-skeleton.c:227
#17 0x00007fc1e79fa88e in _dlerror_run (operate=operate@entry=0x7fc1e79fad30 <dlopen_doit>, args=args@entry=0x7ffcf694c3b0) at dlerror.c:138
#18 0x00007fc1e79fae18 in dlopen_implementation (dl_caller=<optimized out>, mode=<optimized out>, file=0x7fc1e76de620 "/lib64/libsoftokn3.so") at dlopen.c:71
#19 ___dlopen (file=file@entry=0x7fc1e76de620 "/lib64/libsoftokn3.so", mode=<optimized out>) at dlopen.c:81
#20 0x00007fc1e79478eb in pr_LoadLibraryByPathname (flags=26, name=0x7fc1e76de620 "/lib64/libsoftokn3.so") at linking/prlink.c:584
#21 PR_LoadLibraryWithFlags (libSpec=..., flags=flags@entry=26) at linking/prlink.c:386
#22 0x00007fc1dc4489ac in loader_LoadLibInReferenceDir
(referencePath=referencePath@entry=0x7fc1e76de460 "/lib64/libnss3.so", name=name@entry=0x7fc1dc565440 "libsoftokn3.so")
at /usr/src/debug/mozilla-nss-3.70-1.1.x86_64/nss/lib/util/secload.c:85
#23 0x00007fc1dc448a19 in PORT_LoadLibraryFromOrigin
(existingShLibName=existingShLibName@entry=0x7fc1dc56544f "libnss3.so", staticShLibFunc=staticShLibFunc@entry=0x7fc1dc4b5670 <softoken_LoadDSO>, newShLibName=newShLibName@entry=0x7fc1dc565440 "libsoftokn3.so") at /usr/src/debug/mozilla-nss-3.70-1.1.x86_64/nss/lib/util/secload.c:151
#24 0x00007fc1dc4b568e in softoken_LoadDSO () at ../pk11wrap/pk11load.c:373

Ok, there is a bit of (understandable) confusion around this issue, because these are actually 2 separate issues mixed together, because they somehow showed up more or less at the same time!

So let me quickly elaborate:

  1. The sandbox problem. (open)SUSE has several FIPS-related patches to NSS for FIPS-certification. Mozilla introduced a new sandbox (for Socket Processes), which didn't play well with our patches. We had to allow a few more access-rights to some proc-files. This has been upstreamed in bug 1736990. Since no other distro is using our NSS patches (as far as we know), nobody else should be affected by this. But it also has not yet been released on openSUSE Tumbleweed, because of issue number 2.

  2. Firefox freezes when visiting certain webpages. This is currently a mystery and is being actively investigated on openSUSE-side. The few pieces we know is that there was no code change to Firefox. Something in the toolchain beneath Firefox got updated, caused a rebuild and after that point Firefox was showing this issue. The joys of rolling releases.

Thus I would let this bug stay open, as the title is about those freezes.
If you have however stack-traces with "Check for system-wide FIPS mode is required and %s cannot be opened for reading - aborting" in them, this is not this issue and has already been resolved.

I updated to mozilla:Factory's openSUSE_Factory in the meantime:
$ rpm -q MozillaFirefox
MozillaFirefox-93.0-945.1.x86_64
$ rpm -q MozillaFirefox --changelog |head -3

  • Rebase mozilla-sandbox-fips.patch to punch another hole in the
    sandbox containment, to be able to open /proc/sys/crypto/fips_enabled

So monitoring this issue (and not the fixed/fips one).

I can confirm some sites are freezing. I first noticed it with my bank's website, which is why I thought it was related to the FIPS and NSS.

But I also reproduced it earlier tonight trying to buy tickets to Dune on https://experience.regmovies.com/. It might still be related to crypto, but doesn't look like it. I did manage to buy tickets if I didn't wait too long. The first time it did because I had to go find my wallet.

(In reply to jiri slaby from comment #2)

Hmm, there are many threads waiting for a mutex:
mozilla::detail::ConditionVariableImpl::wait(mozilla::detail::MutexImpl&)

Is this a deadlock?

And it's still having the same symptoms. Many threads of many FF processes are waiting for this mutex.

(In reply to jiri slaby from comment #14)

(In reply to jiri slaby from comment #2)

Hmm, there are many threads waiting for a mutex:
mozilla::detail::ConditionVariableImpl::wait(mozilla::detail::MutexImpl&)

Is this a deadlock?

And it's still having the same symptoms. Many threads of many FF processes are waiting for this mutex.

Or not, it's just mEventsAvailable.Wait(), not a mutex per se.

(In reply to jiri slaby from comment #14)

And it's still having the same symptoms. Many threads of many FF processes are waiting for this mutex.

I was not explicit, but the SocketProcess crashes are gone as expected by the update of FF, these freezes remain.

I can confirm that Firefox 93.0 also freezes on Gentoo after visiting for example this webpage:
https://www.newgrounds.com/portal/view/816868

Steps to reproduce:

  1. Open e.g. https://www.newgrounds.com/portal/view/816868
  2. Play the game for a while.
  3. Close the tab.
  4. Open a new tab and load another page.
  5. Firefox will freeze within 5 seconds now. Animations on the loaded page will continue playing but the browser window will not respond to any input events.

Note: I'm using Firefox built from sources with custom build configuration. I can't install the official Mozilla binary due to dependency conflict.

Increasing severity as this forces me to use chromium for many websites.

Severity: -- → S2

This has been (very likely) identified as a toolchain-issue downstream: https://bugzilla.opensuse.org/show_bug.cgi?id=1192067

Using Rust 1.55 + LLVM13 seems to be faulty somehow, but it is not yet clear how or why.

So I don't think, this is an upstream bug.

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → MOVED
See Also: → https://bugzilla.opensuse.org/show_bug.cgi?id=1192067
See Also: → 1740260
See Also: → 1740973
Resolution: MOVED → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: