Firefox Nightly crashes on a webpage since 2 days on Linux
Categories
(Core :: Disability Access APIs, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr78 | --- | unaffected |
| firefox82 | --- | unaffected |
| firefox83 | --- | unaffected |
| firefox84 | --- | affected |
People
(Reporter: foss, Unassigned)
References
(Regression, )
Details
(Keywords: nightly-community, regression)
Attachments
(1 file)
|
30.59 KB,
text/plain
|
Details |
Hello,
Environment:
- Debian 10 GNU/Linux
- Firefox Nightly
Steps to reproduce:
- On a fresh profile or an existing profile, open this page: https://www.lopinion.fr/edition/politique/laicite-republique-mains-qui-ne-tremblent-pas-tribune-lova-rinel-cran-227293
- Click to accept all cookies
Result:
Firefox freezes. I can't do another action. I just can kill it.
Expected result:
Firefox should crash.
mozregression gives me the following result:
14:46.87 INFO: Last good revision: 77c34aa0aaf3b522e2e28e2d2d0ee25a3fa5fc42
14:46.87 INFO: First bad revision: fca112f8825ff7ef6c74ade7ed5cd7acc770ac37
14:46.87 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=77c34aa0aaf3b522e2e28e2d2d0ee25a3fa5fc42&tochange=fca112f8825ff7ef6c74ade7ed5cd7acc770ac37
Note:
I'm not 100% sure but I pretty sure I also reproduced this issue on Linkedin.
Thanks in advance.
|
||
Updated•5 years ago
|
|
||
Updated•5 years ago
|
|
||
Comment 1•5 years ago
|
||
The URL works fine for me. It takes a while for the page to fully load, b/c it has TONS of ads, but it does finish eventually.
I see no difference in a local build, with or without the patch for bug 1672527.
|
Reporter | |
Comment 2•5 years ago
|
||
(In reply to Mats Palmgren (:mats) from comment #1)
The URL works fine for me. It takes a while for the page to fully load, b/c it has TONS of ads, but it does finish eventually.
I see no difference in a local build, with or without the patch for bug 1672527.
Do you have tested on Linux or on another platform?
What can I do to help debugging this?
|
|
Reporter | |
Comment 3•5 years ago
|
||
Launching Firefox from the command-line give me those lines:
###!!! [Child][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost
###!!! [Child][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
|
|
||
Comment 4•5 years ago
|
||
It works fine for me on both Linux and OSX.
Try saving the page to disk in the Firefox version that works and then load that saved copy in the newer version - does it still freeze?
|
|
Reporter | |
Comment 5•5 years ago
|
||
Last but not least:
I reproduce it 100% of the time.(In reply to Mats Palmgren (:mats) from comment #4)
It works fine for me on both Linux and OSX.
Try saving the page to disk in the Firefox version that works and then load that saved copy in the newer version - does it still freeze?
In this morning FF Nightly release, it now works for me both with local version and remote version.
|
|
||
Comment 6•5 years ago
|
||
Ok, good to hear it's working again. Please reopen this bug if the problem comes back. Thanks!
|
|
Reporter | |
Comment 7•5 years ago
|
||
(In reply to Mats Palmgren (:mats) from comment #6)
Ok, good to hear it's working again. Please reopen this bug if the problem comes back. Thanks!
Unfortunately, few minutes after my last message, the issue comes back. I'm not 100% sure if my mozregression test was good. I'll try to another one to ensure it was correct. I reproduce on many website so it's not website specific.
|
|
||
Comment 8•5 years ago
|
||
Ok, I would be very surprised if that change could cause something like this.
Maybe the freeze is a deadlock of some kind? If so, it could be the same underlying cause as bug 1672560. The offending bug 1671619 got backed out yesterday, so if you could try with the 2020-10-24 Nightly that has that backout would be good. (if it still freezes we can hunt for something else)
|
|
Reporter | |
Comment 9•5 years ago
|
||
I'm sorry but I'm pretty sure now that my mozregression session was incorrect.
With the same URL, sometimes the issue comes at first tab, some others at second, some other after opening the fourth tab. So it's quite difficult to ensure if a build is really good or bad.
I'll do another mozregression test in the week-end with at least 4 tabs open to ensure to reproduce the issue correctly when trying.
|
|
Reporter | |
Comment 10•5 years ago
|
||
I confirm I still reproduce even in latest nightly.
A new mozregression gives me this:
31:52.97 INFO: Last good revision: 2a46f29c8cdd6f6269483e86c6e21e649ffa7127
31:52.97 INFO: First bad revision: 4c3e6fb95aa6184651f215d466e702ff7d1660d3
31:52.97 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2a46f29c8cdd6f6269483e86c6e21e649ffa7127&tochange=4c3e6fb95aa6184651f215d466e702ff7d1660d3
My steps was:
- On a fresh profile or an existing profile, open this page: https://www.lopinion.fr/edition/politique/laicite-republique-mains-qui-ne-tremblent-pas-tribune-lova-rinel-cran-227293
- Click to accept all cookies
- Open a second tab, wait 5 seconds
- Open a third tab, wait 5 seconds
- Open a fourth tab, wait 5 seconds
If Firefox doesn't freeze, I considered it's a good build, working I mark the build as bad.
Hope this new mozregression will make more sense.
|
|
||
Updated•5 years ago
|
|
||
Comment 11•5 years ago
|
||
If you run firefox with MOZ_DISABLE_RDD_SANDBOX=1
MOZ_DISABLE_RDD_SANDBOX=1 /path/to/firefox
can you still reproduce the problem?
|
|
||
Updated•5 years ago
|
|
|
Reporter | |
Comment 12•5 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #11)
If you run firefox with MOZ_DISABLE_RDD_SANDBOX=1
MOZ_DISABLE_RDD_SANDBOX=1 /path/to/firefoxcan you still reproduce the problem?
It seems it doesn't make any difference. Do you know how could I verify if the argument worked?
|
|
||
Comment 13•5 years ago
|
||
please provide a copy of the about:support data.
What prefs did you modify?
|
|
Reporter | |
Comment 14•5 years ago
|
||
|
|
Reporter | |
Comment 15•5 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #13)
please provide a copy of the about:support data.
Here it is.
What prefs did you modify?
As I reproduce it on a fresh profile without any modications, I paste you the json-like version of about:support.
I've switched from one computer to another one with a completely different hardware and a cleaner Debian install (just few packages installed) and I still reproduce the issue on it.
|
||
Comment 16•5 years ago
|
||
Hi,
I reproduce the bug, but also I experience such freezes in other contexts. More or less randomly, I have a freeze when I open discord or twitter, ie. some websites with high activity on the page. I can only force the app to exit
That is a very big problem as it makes websites hardly usable in general
Best regards
|
|
Reporter | |
Comment 17•5 years ago
|
||
(In reply to Jean-Philippe MENGUAL from comment #16)
Hi,
I reproduce the bug, but also I experience such freezes in other contexts. More or less randomly, I have a freeze when I open discord or twitter, ie. some websites with high activity on the page. I can only force the app to exit
That is a very big problem as it makes websites hardly usable in general
Best regards
Jean-Philippe and I use assistive technologies, for me it's screen magnifier and for Jean-Philippe it's the Orca screen reader.
I stopped using Nightly because it crashes too frequently.
|
||
Comment 18•5 years ago
|
||
I cannot reproduce this on Windows unfortunately.
|
|
||
Updated•5 years ago
|
|
||
Comment 19•5 years ago
|
||
This looks a lot like bug 1673192 to me. I can reproduce the hang. Here are stacks from main and content respectively:
#0 0x00007ffff7f901b8 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
at /lib64/libpthread.so.0
#1 0x0000555555687d9c in mozilla::detail::ConditionVariableImpl::wait_for(mozilla::detail::MutexImpl&, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator> const&) (this=0x7fffb2aef1c0, lock=..., a_rel_time=...)
at mozglue/misc/ConditionVariable_posix.cpp:142
#2 0x00007fffe6b8f680 in mozilla::OffTheBooksCondVar::Wait(mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator>)
(this=0x7fffb2aef1b8, aDuration=...)
at objdir-linux/dist/include/mozilla/CondVar.h:64
#3 0x00007fffe6b8b379 in mozilla::Monitor::Wait(mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator>)
(this=0x7fffb2aef190, aDuration=...)
at objdir-linux/dist/include/mozilla/Monitor.h:36
#4 0x00007fffe778f263 in mozilla::ipc::MessageChannel::WaitForSyncNotify(bool) (this=0x7fffb29fd0c0)
at ipc/glue/MessageChannel.cpp:2339
#5 0x00007fffe778e941 in mozilla::ipc::MessageChannel::Send(mozilla::UniquePtr<IPC::Message, mozilla::DefaultDelete<IPC::Message> >, IPC::Message*)
(this=0x7fffb29fd0c0, aMsg=
[(IPC::Message *) 0x0], aReply=0x7fffffffb1b8)
at ipc/glue/MessageChannel.cpp:1514
#6 0x00007fffe779943f in mozilla::ipc::IProtocol::ChannelSend(IPC::Message*, IPC::Message*)
(this=0x7fffb9603120, aMsg=0x7fff98d28270, aReply=0x7fffffffb1b8)
at ipc/glue/ProtocolUtils.cpp:518
#7 0x00007fffe7abe1cf in mozilla::a11y::PDocAccessibleParent::SendURL(unsigned long const&, nsTString<char16_t>*)
(this=0x7fffb9603120, aID=@0x7fffb9603190: 0, aURL=0x7fffffffb2f0)
at PDocAccessibleParent.cpp:7566
#8 0x00007fffee3a8b55 in mozilla::a11y::ProxyAccessible::URL(nsTString<char16_t>&) (this=0x7fffb9603170, aURL=u"")
at accessible/ipc/other/ProxyAccessible.cpp:834
#9 0x00007fffee3008b8 in getDocumentAttributeValueCB(_AtkDocument*, char const*) (aDocument=0x7fff9bdfe8f0, aAttrName=0x7fffcff1b004 "DocURL")
at accessible/atk/nsMaiInterfaceDocument.cpp:127
#10 0x00007ffff5f7362a in impl_GetAttributeValue
(bus=<optimized out>, message=0x7fffc9e7ca00, user_data=0x7fff9bdfe8f0) at ../atk-adaptor/adaptors/document-adaptor.c:86
content:
#0 0x00007ffff7ebfe92 in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0
#1 0x0000555555687b67 in mozilla::detail::ConditionVariableImpl::wait(mozilla::detail::MutexImpl&)
(this=0x7fffb2559e18, lock=...)
at mozglue/misc/ConditionVariable_posix.cpp:108
#2 0x00007fffe6b584a8 in mozilla::OffTheBooksCondVar::Wait() (this=0x7fffb2559e10)
at objdir-linux/dist/include/mozilla/CondVar.h:57
#3 0x00007fffe6b879ae in mozilla::Monitor::Wait() (this=0x7fffb2559de8)
at objdir-linux/dist/include/mozilla/Monitor.h:35
#4 0x00007fffe6c5d2a8 in mozilla::MonitorAutoLock::Wait() (this=0x7ffffffee218)
at objdir-linux/dist/include/mozilla/Monitor.h:71
#5 0x00007fffe6c5d046 in mozilla::SyncRunnable::DispatchToThread(nsIEventTarget*, bool)
(this=0x7fffb2559dc0, aThread=0x7fffcf7f1030, aForceDispatch=false)
at objdir-linux/dist/include/mozilla/SyncRunnable.h:71
#6 0x00007fffe6c4d2d6 in mozilla::SyncRunnable::DispatchToThread(nsIEventTarget*, nsIRunnable*, bool)
(aThread=0x7fffcf7f1030, aRunnable=0x7fffb2566d80, aForceDispatch=false)
at objdir-linux/dist/include/mozilla/SyncRunnable.h:102
#7 0x00007fffeaea96f5 in mozilla::RemoteDecoderManagerChild::Supports(mozilla::RemoteDecodeIn, mozilla::SupportDecoderParams const&, mozilla::DecoderDoctorDiagnostics*)
(aLocation=mozilla::RddProcess, aParams=..., aDiagnostics=0x0)
at dom/media/ipc/RemoteDecoderManagerChild.cpp:216
#8 0x00007fffeaeb9928 in mozilla::RemoteDecoderModule::Supports(mozilla::SupportDecoderParams const&, mozilla::DecoderDoctorDiagnostics*) const (this=0x7fffc1d4b7e0, aParams=..., aDiagnostics=0x0)
at dom/media/ipc/RemoteDecoderModule.cpp:58
#9 0x00007fffeafeaed5 in mozilla::PDMFactory::GetDecoderModule(mozilla::SupportDecoderParams const&, mozilla::DecoderDoctorDiagnostics*) const (this=0x7fffc1d47af0, aParams=..., aDiagnostics=0x0)
at dom/media/platforms/PDMFactory.cpp:517
#10 0x00007fffeafeadb2 in mozilla::PDMFactory::Supports(mozilla::SupportDecoderParams const&, mozilla::DecoderDoctorDiagnostics*) const (this=0x7fffc1d47af0, aParams=..., aDiagnostics=0x0)
at dom/media/platforms/PDMFactory.cpp:369
#11 0x00007fffeb42d260 in mozilla::MP4Decoder::IsSupportedType(mozilla::MediaContainerType const&, mozilla::DecoderDoctorDiagnostics*) (aType=..., aDiagnostics=0x0)
at dom/media/mp4/MP4Decoder.cpp:175
#12 0x00007fffeaaa7fbe in mozilla::CanHandleCodecsType(mozilla::MediaContainerType const&, mozilla::DecoderDoctorDiagnostics*) (aType=..., aDiagnostics=0x7ffffffee928)
at dom/media/DecoderTraits.cpp:106
#13 0x00007fffeaaa71f5 in mozilla::CanHandleMediaType(mozilla::MediaContainerType const&, mozilla::DecoderDoctorDiagnostics*) (aType=..., aDiagnostics=0x7ffffffee928)
at dom/media/DecoderTraits.cpp:161
#14 0x00007fffeaaa714d in mozilla::DecoderTraits::CanHandleContainerType(mozilla::MediaContainerType const&, mozilla::DecoderDoctorDiagnostics*) (aContainerType=..., aDiagnostics=0x7ffffffee928)
at dom/media/DecoderTraits.cpp:200
#15 0x00007fffea9b9499 in mozilla::dom::HTMLMediaElement::GetCanPlay(nsTSubstring<char16_t> const&, mozilla::DecoderDoctorDiagnostics*) (aType=..., aDiagnostics=0x7ffffffee928)
at dom/html/HTMLMediaElement.cpp:4940
#16 0x00007fffea9c3b34 in mozilla::dom::HTMLMediaElement::CanPlayType(nsTSubstring<char16_t> const&, nsTSubstring<char16_t>&) (this=0x7fffc7060800, aType=..., aResult=...)
at dom/html/HTMLMediaElement.cpp:4957
#17 0x00007fffea144b72 in mozilla::dom::HTMLMediaElement_Binding::canPlayType(JSContext*, JS::Handle<JSObject*>, void*, JSJitMethodCallArgs const&) (cx=0x7fffcf52f000, obj=..., void_self=0x7fffc7060800, args=...)
at HTMLMediaElementBinding.cpp:519
#18 0x00007fffea22e671 in mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions>(JSContext*, unsigned int, JS::Value*)
(cx=0x7fffcf52f000, argc=1, vp=0x7fffcbe624f0)
at dom/bindings/BindingUtils.cpp:3229
#19 0x00007fffeebe5d56 in CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&)
(cx=0x7fffcf52f000, native=0x7fffea22dfc0 <mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions>(JSContext*, unsigned int, JS::Value*)>, reason=js::Call, args=...) at js/src/vm/Interpreter.cpp:507
|
|
||
Comment 20•5 years ago
|
||
Hi,
@alexarnaud, could you try your step-to-step in another window manager, eg. Marco? Here it seems to make things more stable. Would imply your COmpiz then.
Regards
|
|
||
Comment 21•5 years ago
|
||
Seems to be the same as bug 1673192.
A fix has been pushed with bug 1674043 and hopefully will be available tomorrow
Description
•