Code change:
YouTube tabs reliably crash within a few minutes on nixpkgs-built firefox Steps to reproduce the behavior: firefox from latest (NixOS/nixpkgs to some youtube user's video list up and down for a bit This doesn't happen with my previous env (using firefox 92.0.1, I think NixOS/nixpkgs but I haven't confirmed), nor with . It does happen with . Also, the page is not available on the nixpkgs-built firefox. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I think it happens when you hover over a video and it starts showing the preview.
Yep that does it!
Possibly this bug?
Seems familiar. Will try the fix they suggest.
Note that in bisecting I've found a commit with the same version of ff but not this bug.
I don't think it's the same bug, I'm able to watch both linked videos (as long as I don't mouse-over a preview on the side)
It's happening for me as well, not sure why though
Not happening with firefox-bin 94.0
As said in the issue it doesn't happen with firefox-bin at all (also checked that myself) (also not 94.0.1)
Also happening for me (using nixpkgs.firefox).
Hotlinking directly to webp files also recreates the issue. That should narrow it down a bit. [edit: I guess these links expire after some time, but its just the url to an animated youtube thumbnail]
Also works on firefox-bin 94.0.1 (master is on 94.0).
Seeing crash locally as well on and . I bisected down to (had to apply to avoid build failures). It is a merge commit with the following conflict resolution:
While at it how does one get meaningful debug symbols out of firefox? is very sad: I tried patching in the below, but got no symbols: Is there a generic way to get the symbols? Or maybe it's a good opportunity to add them to specifically?
I tried reverting , still broken. Worked when 94.0.1 was merged in .
Yeah, I have no idea on how to accomplish that either. And having that could be really helpful :+1:
I can confirm this occurs when mousing over YouTube video link/thumbnail pairs in either the main page, search results or video sidebar (on Firefox 94.0.1). Not only that but doesn't exist at all, which probably means the crash reporting feature is entirely disabled for nixpkgs Firefox?
With the stdenv patch, does ff work on both parents of the merge commit but not the commit itself?
we have crashreporter turned off by default for some reason
its been that way since (2008) we should set it to
Crash report: https://crash-
correct. Re-tested again just in case: ^0: - crash ^1: - ok ^2: - ok ^3: <invalid, only 2 parentsNote that these two branches contain about 2 weeks of commits. One of them is a update, another is an update. This merge mixes both together and firefox does not seem to work. is a full picture of all the commits involved. Anecdotally I tried to disable lto with and got working (but I suspect it also flips to in that case). Would be nice if controlled just aspect and not the rest of toolchain.
Although using is possible for LTO ultimately it complicates the expression and deviates from upstream. When I implemented support for LTO, I think it was agreed upon that we should try to follow upstream as close as possible. Hence enforcing and . The reduced maintenance burden of having to test more configurations was also a plus. That being said it would be nice if someone wants to take on that burden and expand the LTO support to be more general (and maintain it). The end goal was to actually change to build to using too but allow the native system linker. I never got around to implementing that. The reasoning being upstream tests vigorously against . This is speculation on my part but I think a point of interest here is Firefox now builds against instead of . Building with was never a requirement for LTO but a side effect of the old stdenv. At the time did not have a proper nixpkgs wrapper script and was unable to be used outside of it. (On a side note, for some reason had issues during linking with not being configured to pull in LLVM's hence the workaround. It can be removed now since is being used.) reports (about:buildconfig) being built with LLVM 12 and rustc 1.55 so this might be a new bug introduced with LLVM 13 or the newer rustc. A definitive way to test if it is a bug in the switch to would be keeping the same firefox version and having applied (so is used) but change the underlying LLVM and rustc versions to 12 and 1.55 respectively. If the crash goes away then it is tied to the LLVM and rustc version if not then something wrong is happening when using .
I created a upstream bug 3 days ago, including stack backtrace with symbols. The crash function is in . Disabling webp () can mitigate but it of course quite hurt. :disappointed: If anyone gets more information, please also post in the bug thread. BTW: Enabling debug symbols need to set configure flags and set . won't work due to .
It is mentioned in that bug report that directly opening links canot reproduce the crash. I actually had the opposite experience. I was able to recreate the crash by directly opening a webp file, although it's not 100% consistent. I also stumbled across this other URL that crashes firefox, this one is a PNG. If I right-click this URL and "Open in new window" the tab will crash about 50% of the time. Curiously, this URL seems unaffected, despite the resulting file being hash-identical. !
I just now noticed that the above image is being served with a content-type, so looks like its still webp-specific, even though no webp content is being actually rendered.
I cannot reproduce with that URL at all after tens of tries. This DOES crash me sometimes. And note that the URL actually responds a WEBP image despite it contains , maybe due to HTTP fields. You can confirm it by the tab title (once you don't crash) or download and check with . This is also fine for me. It's more complex than I think. I'll guess it might be an index-out-of-bound or other kind of heap corruption? Could you post about this in my bugzilla report?
Can you share exact change needed? Here is my non-working example of enabling the symbols:
Yeah, whatever optimization tricks is doing here is just confusing things. I'm going to ignore those results for now. I was able to create a very small poc for the bug that works reliably with the same image, though. (Also posted in the bugzilla thread)
For how to build with debug symbols, see I'm still working on this issue now and I'll make a PR about that later. Note that you need to follow and set environment before starting or .
This is happening for me.
See
the in the first post is a typo, right? If I read it right, we can keep stable nixpkgs as it is, thanks to using LLVM 12 for firefox.
Yes, updated.

Related discussion:
text: # > the experience of Firefox users, you won't have any issues using the # > official branding. , enableOfficialBranding ? true <ins> # On 32bit platforms, we disable adding "-g" for easier linking. , enableDebugSymbols ? !stdenv.is32bit </ins> }: assert stdenv.cc.libc or null != null;