info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#998108: firefox freezes shortly after start
2 views
Skip to first unread message
Josh Triplett
Nov 2, 2021, 8:30:03 AM11/2/21
to
On Sat, 30 Oct 2021 15:04:01 +0200 Christoph Anton Mitterer <cale...@scientia.net> wrote:
> Since about yesterday (possibly since the rebuilt package came in)
> firefox freezes shortly after being started.
> There is no high CPU activity then, it just takes no input anymore
> (no keyboard, no mouse clicks).
> This also happens in --safe-mode.
I'm encountering this as well. It happens slower if I just browse, and
much much faster if I use something like WebGL.
> Since about yesterday (possibly since the rebuilt package came in)
> firefox freezes shortly after being started.
> There is no high CPU activity then, it just takes no input anymore
> (no keyboard, no mouse clicks).
> This also happens in --safe-mode.
I'm encountering this as well. It happens slower if I just browse, and
much much faster if I use something like WebGL.
Dmitry Shachnev
Nov 3, 2021, 6:00:04 AM11/3/21
to
Control: found -1 firefox/94.0-1
Hi all,
On Sat, Oct 30, 2021 at 03:04:01PM +0200, Christoph Anton Mitterer wrote:
> Package: firefox
> Version: 93.0-1+b1
> Severity: grave
> Justification: renders package unusable
>
> Hey.
94.0-1 update.
--
Dmitry Shachnev
Hi all,
On Sat, Oct 30, 2021 at 03:04:01PM +0200, Christoph Anton Mitterer wrote:
> Package: firefox
> Version: 93.0-1+b1
> Severity: grave
> Justification: renders package unusable
>
> Hey.
>
> Since about yesterday (possibly since the rebuilt package came in)
> firefox freezes shortly after being started.
> There is no high CPU activity then, it just takes no input anymore
> (no keyboard, no mouse clicks).
> This also happens in --safe-mode.
I had this bug too with 93.0-1+b1, and it still happens with today's
> Since about yesterday (possibly since the rebuilt package came in)
> firefox freezes shortly after being started.
> There is no high CPU activity then, it just takes no input anymore
> (no keyboard, no mouse clicks).
> This also happens in --safe-mode.
94.0-1 update.
--
Dmitry Shachnev
David Heidelberg
Nov 3, 2021, 11:10:03 AM11/3/21
to
HW: Intel i7-7500U; 16G RAM; GPU HD Graphics 620
Debian: unstable
System: amd64
Session: GNOME with Wayland.
Firefox: 93-b1 - 94
Random freezes. 10 seconds up to X minutes, depending on the websites
tab opened.
Best regards
David Heidelberg
Debian: unstable
System: amd64
Session: GNOME with Wayland.
Firefox: 93-b1 - 94
Random freezes. 10 seconds up to X minutes, depending on the websites
tab opened.
Best regards
David Heidelberg
dirdi
Nov 6, 2021, 9:40:03 AM11/6/21
to
Package: firefox
Version: 94.0-1
Followup-For: Bug #998108
X-Debbugs-Cc: deb...@dirdi.name
As a first step it would be good to have a method - e.g. a crafted HTML page - to crash firefox instantly and reproducible. This would enable us to bisect the changes between 93.0-1 and 93.0-1+b1.
Package-specific info:
-- Addons package information
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing'), (50, 'unstable'), (5, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_DIE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages firefox depends on:
ii debianutils 4.11.2
ii fontconfig 2.13.1-4.2
ii libatk1.0-0 2.36.0-2
ii libc6 2.32-4
ii libcairo-gobject2 1.16.0-5
ii libcairo2 1.16.0-5
ii libdbus-1-3 1.12.20-3
ii libdbus-glib-1-2 0.112-2
ii libevent-2.1-7 2.1.12-stable-1
ii libffi8 3.4.2-3
ii libfontconfig1 2.13.1-4.2
ii libfreetype6 2.11.0+dfsg-1
ii libgcc-s1 11.2.0-10
ii libgdk-pixbuf-2.0-0 2.42.6+dfsg-2
ii libglib2.0-0 2.70.0-3
ii libgtk-3-0 3.24.30-3
ii libnspr4 2:4.32-1
ii libnss3 2:3.72-1
ii libpango-1.0-0 1.48.10+ds1-1
ii libstdc++6 11.2.0-10
ii libvpx7 1.11.0-2
ii libx11-6 2:1.7.2-2+b1
ii libx11-xcb1 2:1.7.2-2+b1
ii libxcb-shm0 1.14-3
ii libxcb1 1.14-3
ii libxcomposite1 1:0.4.5-1
ii libxdamage1 1:1.1.5-2
ii libxext6 2:1.3.4-1
ii libxfixes3 1:5.0.3-2
ii libxrandr2 2:1.5.2-1
ii procps 2:3.3.17-5
ii zlib1g 1:1.2.11.dfsg-2
Versions of packages firefox recommends:
ii libavcodec58 7:4.4.1-1+b1
Versions of packages firefox suggests:
pn fonts-lmodern <none>
pn fonts-stix | otf-stix <none>
ii libcanberra0 0.30-8
ii libgssapi-krb5-2 1.18.3-7
ii pulseaudio 15.0+dfsg1-2
-- no debconf information
Version: 94.0-1
Followup-For: Bug #998108
X-Debbugs-Cc: deb...@dirdi.name
As a first step it would be good to have a method - e.g. a crafted HTML page - to crash firefox instantly and reproducible. This would enable us to bisect the changes between 93.0-1 and 93.0-1+b1.
Package-specific info:
-- Addons package information
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing'), (50, 'unstable'), (5, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_DIE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages firefox depends on:
ii debianutils 4.11.2
ii fontconfig 2.13.1-4.2
ii libatk1.0-0 2.36.0-2
ii libc6 2.32-4
ii libcairo-gobject2 1.16.0-5
ii libcairo2 1.16.0-5
ii libdbus-1-3 1.12.20-3
ii libdbus-glib-1-2 0.112-2
ii libevent-2.1-7 2.1.12-stable-1
ii libffi8 3.4.2-3
ii libfontconfig1 2.13.1-4.2
ii libfreetype6 2.11.0+dfsg-1
ii libgcc-s1 11.2.0-10
ii libgdk-pixbuf-2.0-0 2.42.6+dfsg-2
ii libglib2.0-0 2.70.0-3
ii libgtk-3-0 3.24.30-3
ii libnspr4 2:4.32-1
ii libnss3 2:3.72-1
ii libpango-1.0-0 1.48.10+ds1-1
ii libstdc++6 11.2.0-10
ii libvpx7 1.11.0-2
ii libx11-6 2:1.7.2-2+b1
ii libx11-xcb1 2:1.7.2-2+b1
ii libxcb-shm0 1.14-3
ii libxcb1 1.14-3
ii libxcomposite1 1:0.4.5-1
ii libxdamage1 1:1.1.5-2
ii libxext6 2:1.3.4-1
ii libxfixes3 1:5.0.3-2
ii libxrandr2 2:1.5.2-1
ii procps 2:3.3.17-5
ii zlib1g 1:1.2.11.dfsg-2
Versions of packages firefox recommends:
ii libavcodec58 7:4.4.1-1+b1
Versions of packages firefox suggests:
pn fonts-lmodern <none>
pn fonts-stix | otf-stix <none>
ii libcanberra0 0.30-8
ii libgssapi-krb5-2 1.18.3-7
ii pulseaudio 15.0+dfsg1-2
-- no debconf information
小太
Nov 11, 2021, 7:10:03 AM11/11/21
to
I narrowed down the freeze to the cubeb pulse code (part of the audio library
firefox uses), and I found that it was actually fixed almost a month ago:
https://github.com/mozilla/cubeb-pulse-rs/pull/72
It's already been merged into firefox on-track for v95:
https://bugzilla.mozilla.org/show_bug.cgi?id=1735905
A separate user confirmed on the openSUSE bug that it was fixed with the change:
https://bugzilla.opensuse.org/show_bug.cgi?id=1192067#c30
So either the change needs to be backported to v94, or we'll just have to wait
until v95 (or compile the browser ourselves)
firefox uses), and I found that it was actually fixed almost a month ago:
https://github.com/mozilla/cubeb-pulse-rs/pull/72
It's already been merged into firefox on-track for v95:
https://bugzilla.mozilla.org/show_bug.cgi?id=1735905
A separate user confirmed on the openSUSE bug that it was fixed with the change:
https://bugzilla.opensuse.org/show_bug.cgi?id=1192067#c30
So either the change needs to be backported to v94, or we'll just have to wait
until v95 (or compile the browser ourselves)
小太
Nov 11, 2021, 12:40:03 PM11/11/21
to
On Thu, 11 Nov 2021 23:06:44 +1100 =?UTF-8?B?4oCN5bCP5aSq?=
<nos...@kota.moe> wrote:
> So either the change needs to be backported to v94, or we'll just have to wait
> until v95 (or compile the browser ourselves)
I was a bit adventurous and tried doing a binary patch on the current debian
<nos...@kota.moe> wrote:
> So either the change needs to be backported to v94, or we'll just have to wait
> until v95 (or compile the browser ourselves)
version (94.0-1), and got it working.
If you open /usr/lib/firefox/libxul.so in a hex editor and go to file offset
0x46a4703, you can perform a find and replace with the below hex strings:
find: 498B5C2408904889DFFF157FBD9703EBF5
replace: 4D8B6C2408904C89EFFF157FBD9703EBDA
This effectively performs the following changes to the binary:
--- libxul.so.S.before 2021-11-12 03:15:52.985702747 +1100
+++ libxul.so.S.after 2021-11-12 04:13:27.364102267 +1100
@@ -18661992,15 +18661992,15 @@
4e956f2: 41 ff d5 call *%r13
4e956f5: 48 8d 0d cc 87 96 03 lea 0x39687cc(%rip),%rcx
# 87fdec8 <_ZZNKSt8__detail11_AnyMatcherINSt7__cxx1112regex_traitsIcEELb0ELb0ELb0EEclEcE5__nul@@xul94+0xaed18>
4e956fc: 48 8d 15 cd 87 96 03 lea 0x39687cd(%rip),%rdx
# 87fded0 <_ZZNKSt8__detail11_AnyMatcherINSt7__cxx1112regex_traitsIcEELb0ELb0ELb0EEclEcE5__nul@@xul94+0xaed20>
4e95703: 48 83 7b 40 00 cmpq $0x0,0x40(%rbx)
4e95708: 74 11 je 4e9571b
<atp_promote_thread_to_real_time@@xul94+0xd18bb>
- 4e9570a: 49 8b 5c 24 08 mov 0x8(%r12),%rbx
+ 4e9570a: 4d 8b 6c 24 08 mov 0x8(%r12),%r13
4e9570f: 90 nop
- 4e95710: 48 89 df mov %rbx,%rdi
+ 4e95710: 4c 89 ef mov %r13,%rdi
4e95713: ff 15 7f bd 97 03 call *0x397bd7f(%rip)
# 8811498 <nspr_use_zone_allocator@@xul94+0x5258>
- 4e95719: eb f5 jmp 4e95710
<atp_promote_thread_to_real_time@@xul94+0xd18b0>
+ 4e95719: eb da jmp 4e956f5
<atp_promote_thread_to_real_time@@xul94+0xd1895>
4e9571b: 8b 02 mov (%rdx),%eax
4e9571d: 83 c0 ff add $0xffffffff,%eax
4e95720: 83 f8 01 cmp $0x1,%eax
4e95723: 0f 87 13 02 00 00 ja 4e9593c
<atp_promote_thread_to_real_time@@xul94+0xd1adc>
4e95729: 4c 8b 29 mov (%rcx),%r13
This basically changes the binary such that it no longer infinite loops in the
PulseStream::stop() function, and actually checks self.drain_timer every loop as
it's supposed to
Marco d'Itri
Nov 11, 2021, 4:30:03 PM11/11/21
to
On Nov 11, 小太 <nos...@kota.moe> wrote:
> If you open /usr/lib/firefox/libxul.so in a hex editor and go to file offset
> 0x46a4703, you can perform a find and replace with the below hex strings:
> find: 498B5C2408904889DFFF157FBD9703EBF5
> replace: 4D8B6C2408904C89EFFF157FBD9703EBDA
Great work! Quick one liner:
> If you open /usr/lib/firefox/libxul.so in a hex editor and go to file offset
> 0x46a4703, you can perform a find and replace with the below hex strings:
> find: 498B5C2408904889DFFF157FBD9703EBF5
> replace: 4D8B6C2408904C89EFFF157FBD9703EBDA
sudo perl -i -pe 's/\x49\x8B\x5C\x24\x08\x90\x48\x89\xDF\xFF\x15\x7F\xBD\x97\x03\xEB\xF5/\x4D\x8B\x6C\x24\x08\x90\x4C\x89\xEF\xFF\x15\x7F\xBD\x97\x03\xEB\xDA/' /usr/lib/firefox/libxul.so
--
ciao,
Marco
dirdi
Nov 25, 2021, 10:10:05 AM11/25/21
to
After the upgrade to 94.0-2, I still experienced some crashes, but
disabling hardware acceleration (about:preferences > General >
Performance > uncheck both checkboxes and set processing limit to 8)
fixed it for me.
disabling hardware acceleration (about:preferences > General >
Performance > uncheck both checkboxes and set processing limit to 8)
fixed it for me.
Christoph Anton Mitterer
Dec 3, 2021, 4:30:03 PM12/3/21
to
I just had one occasion of the "freezing" problem... but it was the
first time since we got 94.0-2.
Also it didn't occur short after start, but quite some time after
browsing the very same websites.
But the symptoms were as described in message #15 (i.e. that loading
wheel).
So there may be still some issue left (or it might be something
new/unrelated).
Cheers,
Chris.
first time since we got 94.0-2.
Also it didn't occur short after start, but quite some time after
browsing the very same websites.
But the symptoms were as described in message #15 (i.e. that loading
wheel).
So there may be still some issue left (or it might be something
new/unrelated).
Cheers,
Chris.
0 new messages