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

Steps to reproduce:

On Firefox & Thunderbird running on flatpak in ElementaryOS 6.1 (Linux), I'm trying to print a web page (in Firefox) or a mail (in Thunderbird) using CTRL-P.

More details:

• Linux 5.15.0-79-generic #86~20.04.2-Ubuntu SMP Mon Jul 17 23:27:17 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
• apt installed: flatpak/focal,now 1.12.7-1~ubuntu6.1.1 amd64
• flatpak installed:
  Thunderbird org.mozilla.Thunderbird 115.1.1 stable flathub user
  Firefox org.mozilla.firefox 116.0.3 stable flathub user
• apt installed: libcups2/focal-updates,now 2.3.1-9ubuntu1.4 amd64

Actual results:

Upon each attempt, the application crashes.

I submitted the crash report (see https://crash-stats.mozilla.org/report/index/3770bf61-c91a-4649-bd81-66e2e0230819) and noticed plenty of other, similar reports (see https://crash-stats.mozilla.org/signature/?product=Firefox&signature=libcups.so.2%400x291a5&date=%3E%3D2023-02-27T07%3A21%3A00.000Z&date=%3C2023-08-27T07%3A21%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-date&_sort=-version&page=1).

Expected results:

The print dialog should've appeared and I should've been able to proceed and print.

The Bugbug bot thinks this bug should belong to the 'Core::Printing: Output' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

From the crash report:
Crash report: https://crash-stats.mozilla.org/report/index/3770bf61-c91a-4649-bd81-66e2e0230819

Reason: SIGSEGV / SEGV_MAPERR

Top 10 frames of crashing thread:

0  libc.so.6  __strcasecmp_l_sse42  
1  libcups.so.2  libcups.so.2@0x291a5  
2  libcups.so.2  libcups.so.2@0x29b55  
3  libcups.so.2  libcups.so.2@0x2a117  
4  libxul.so  nsPrinterListCUPS::SystemDefaultPrinterName const  widget/nsPrinterListCUPS.cpp:220
5  libxul.so  NS_InvokeByIndex  
6  libxul.so  CallMethodHelper::Invoke  js/xpconnect/src/XPCWrappedNative.cpp:1627
6  libxul.so  CallMethodHelper::Call  js/xpconnect/src/XPCWrappedNative.cpp:1180
6  libxul.so  XPCWrappedNative::CallMethod  js/xpconnect/src/XPCWrappedNative.cpp:1126
7  libxul.so  XPCWrappedNative::GetAttribute  js/xpconnect/src/xpcprivate.h:1450

It looks like this is a recent regression, and it's flatpak-specific.

There are 704 total crashes, all in the last month. The earliest affected version is 115.0.3:
bp-3294fbe7-5091-4f94-b18a-4e0600230805

Nearly all of the crashes are in v116.* -- however, this is not a regression in 116, since there are a few extremely recent crash reports in older versions, e.g. there are a very small number of recent crashes in Firefox 114.0.1 like this one: bp-881ad048-46e0-4b87-b354-2a5260230827

So it looks like this may not have been a regression in Firefox, but rather a regression in some external package/software (maybe libcups), which we're unlucky enough to be tripping when calling out to get the default printer name.

AlaskanEmily (CC'd) looked into some string-comparison-related CUPS crashes a little while back; I wonder if this is related to those?

I can reproduce the crash, in a VM of elementary 6.1 (fresh install), running flatpak firefox v117.0, after setting up a printer[1].

In the same VM, I can't repro with the official Firefox tarball downloaded directly from Mozilla ( https://www.mozilla.org/en-US/firefox/new/ )

[1] I added a fake printer -- in the system "printer settings" app, I clicked "+" and then chose "CUPS-BRF" under the "file" section, and then chose "Generic | Generic Braille Embosser, 1.0". This was sufficient to get the system to think it has a printer available, and it's sufficient to make flatpak-Firefox insta-crash when I do Ctrl+P.

I thought maybe print.prefer_system_dialog:true might help here, but sadly it does not.

A quick random sampling of flatpak bugs, I see jhorak has fixed some of them. jhorak, perhaps you might know what's going on here, or might know who to point at this?

(I wonder if the flatpak is somehow tripping over a permission when trying to call out to CUPS? I tried running with

Repro's on Elementary 7.0 as well (in a VM).

It also repro's on my native Ubuntu 22.04 installation, when I do
sudo apt install flatpak
...and then use that to install Firefox via the flatref file downloaded from https://flathub.org/apps/org.mozilla.firefox , and then run it (flatpak run org.mozilla.firefox) and then try to print with ctrl+P.

So: AFAICT, this affects anyone using https://flathub.org/apps/org.mozilla.firefox (if they've got any printer configured in CUPS, and they do Ctrl+P)

Aha, the backtrace and STR here look like they match bug 1836764's backtrace and STR from the openprinting issue that spun off of that bug.

Over here, we have:

0  libc.so.6  __strcasecmp_l_sse42  
1  libcups.so.2  libcups.so.2@0x291a5  
2  libcups.so.2  libcups.so.2@0x29b55  
3  libcups.so.2  libcups.so.2@0x2a117  
4  libxul.so  nsPrinterListCUPS::SystemDefaultPrinterName const  widget/nsPrinterListCUPS.cpp:220

Over in bug 1850269, we have:

0  libc.so.6  __strcasecmp_l_avx2  /usr/src/debug/glibc/glibc/sysdeps/x86_64/multiarch/strcmp-avx2.S:283
1  libcups.so.2  cupsCopyDest  
2  libcups.so.2  _cupsSNMPWalk  
3  libcups.so.2  cupsGetNamedDest  
4  libxul.so  nsPrinterListCUPS::SystemDefaultPrinterName const  widget/nsPrinterListCUPS.cpp:220

I suspect the unknown libcups.so.2 stack levels correspond to the corresponding functions that we have symbols for in bug 1850269.

Not sure why it's come back as flatpak-specific somehow, e.g. if flatpak somehow uses a different libcups which is affected by this, or what?

Aha, it looks like we already have bug 1849397 filed for this, and bug 1849397 comment 5 says a fix is on the way in flathub.

bug 1849397 comment 4 has a good summary / explanation (tl;dr: yes, flatpak-firefox does indeed have a different libcups which is affected by this).

Transferred crash signature to dupe-target.