Bug 1881365
Summary: | cups-browsed crashing | ||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Andreas Petzold <andreas.petzold> | ||||||||||||||||||||||||
Component: | cups-filters | Assignee: | Zdenek Dohnal <zdohnal> | ||||||||||||||||||||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||||||||||
Severity: | unspecified | Docs Contact: | |||||||||||||||||||||||||
Priority: | unspecified | ||||||||||||||||||||||||||
Version: | 32 | CC: | imc, twaugh, zdohnal | ||||||||||||||||||||||||
Target Milestone: | --- | ||||||||||||||||||||||||||
Target Release: | --- | ||||||||||||||||||||||||||
Hardware: | x86_64 | ||||||||||||||||||||||||||
OS: | Unspecified | ||||||||||||||||||||||||||
Whiteboard: | |||||||||||||||||||||||||||
Fixed In Version: | cups-filters-1.28.5-1.fc33 cups-filters-1.28.5-1.fc31 cups-filters-1.28.5-1.fc32 | Doc Type: | If docs needed, set a value | ||||||||||||||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||||||||||||||
Clone Of: | Environment: | ||||||||||||||||||||||||||
Last Closed: | 2020-11-08 01:15:19 UTC | Type: | Bug | ||||||||||||||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||||||||||||||
Documentation: | --- | CRM: | |||||||||||||||||||||||||
Verified Versions: | Category: | --- | |||||||||||||||||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||||||||||||
Embargoed: | |||||||||||||||||||||||||||
Attachments: |
|
Description
Andreas Petzold
2020-09-22 09:37:54 UTC
Hi Andreas, thank you for reporting the issue! The issue is clear - strcasestr() cannot find '.Borderless' string in string 'A4', but I don't know the connection between size->media and ppdname strings (if all size->media's are Borderless, then it expects ppdname has .Borderless substring too...). Would you mind running the cups-browsed within valgrind with memcheck ( with cups-filters-debugsource, cups-filters-debuginfo, cups-filters-libs-debuginfo, cups-libs-debuginfo, cups-debugsource installed)? $ sudo valgrind --leak-check=full --log-file=valgrind.log /usr/sbin/cups-browsed just to be sure if there aren't some memory errors there. I prepared a simple hot fix here https://koji.fedoraproject.org/koji/taskinfo?taskID=52462182 . Would you mind testing it too? But please provide the info requested earlier. Thank you in advance! Created attachment 1717802 [details]
valgrind log of cups-browsed
As requested, I've run cups-browsed in valgrind.
Hi Zdenek, (In reply to Zdenek Dohnal from comment #1) > > I prepared a simple hot fix here > https://koji.fedoraproject.org/koji/taskinfo?taskID=52462182 . > > Would you mind testing it too? But please provide the info requested earlier. I've tested your packages from koji and cups-browsed is not crashing! Thanks for the fix! Andreas, please test the printing too - to be sure it doesn't introduce a problem with printing. Hi Zdenek, printing to a printer which was discovered via cups-browsed work fine for me! Andreas, I find the current fix kind of strange, so I'm digging deeper into the code to understand why the damn it got into this place, where it crashed. I'm trying to figure out why all values of 'media' in 'sizes' struct contain '.Borderless' (since 'all_borderless' is still 1), but 'ppdname' is without '.Borderless'. It can happen if 'media-col-default' contains normal media type, and then other attributes regarding media - 'media-col-database', 'media-size-supported' and 'media-supported' - have all borderless types. I find it very strange. I'll send you a gdb script this week to debug this further. Andreas, would you mind running this command: $ sudo gdb -x gdb_script /usr/sbin/cups-browsed with gdb_script (I will upload it shortly) and attach the created gdb_log file here as an attachment? It will run cups-browsed in gdb and collect values of ppdname and all media names. Created attachment 1719931 [details]
GDB script
And would you mind enabling cups-browsed debug logging by adding 'DebugLogging stderr' into /etc/cups/cups-browsed.conf, restarting cups-browsed service, collecting the logs via: $ journalctl -u cups-browsed > browsed.log and attaching the browsed.log as an attachment? Created attachment 1720955 [details]
output of gdb_script
output of gdb_script
Created attachment 1720956 [details]
cups-browsed debug log
cups-browsed debug log
Created attachment 1721170 [details]
GDB script
Thank you for your cooperation so far! I'm deeply sorry, I forgot to add the breakpoint to the script to break on the specific print queue which was being processed when the segfault happened...
So GDB output gave me media sizes for the first processed queue, but the segfault happened when the queue called SCC-CN441OG-A3A4FarbeMFP was being processed, so I would like to check these...
Would you mind running the gdb script again? Logs from debug log are fine, you don't need to reupload them.
*** Bug 1889794 has been marked as a duplicate of this bug. *** Created attachment 1723200 [details]
Output of the new gdb script.
I'm not sure the output is useful. It ends with:
gdb_script (1):12: Error in sourced command file:
No symbol "ppdname" in current context.
Created attachment 1723201 [details]
GDB script
One step missed in GDB script, please rerun it again.
I'm sorry for inconvenience :(
Created attachment 1723213 [details]
gdb_log
This log is what I get (I inserted an extra 'c').
The ppdname is coming from "media-col-default" in the request which has x=21000, y=297000 and all the margins set to 423, so it is not borderless and its name is "A4". However, all the sizes are coming from "media-size-supported" and apparently these do all have margins set to zero. I am not sure why they are zero; but since the information is coming from different sources it seems that it is not a valid assumption that the default media would be borderless just because all of the reported supported media types are borderless (even though that sounds counter-intuitive).
The PPD for this printer is "Ricoh MP C5504 , Postscript-Ricoh 20161206 (OpenPrinting LSB 3.2)" (which came from openprinting.org). It defines roughly 60 media sizes, which is actually a list of 30 media listed twice: the first time with "false setedgetoedge" and the second time with "true setedgetoedge" and "FullBleed" in the media name. So the supported media types in the original PPD are clearly not all borderless, and I don't know where all the values with zero borders in the attached log are coming from.
(In reply to Ian Collier from comment #16) > Created attachment 1723213 [details] > gdb_log > > This log is what I get (I inserted an extra 'c'). Thanks - it seems the code execution differs in my and your cases, so I always update the script regarding your output. > > The ppdname is coming from "media-col-default" in the request which has > x=21000, y=297000 and all the margins set to 423, so it is not borderless > and its name is "A4". However, all the sizes are coming from > "media-size-supported" and apparently these do all have margins set to zero. > I am not sure why they are zero; but since the information is coming from > different sources it seems that it is not a valid assumption that the > default media would be borderless just because all of the reported supported > media types are borderless (even though that sounds counter-intuitive). Ok, that's confirms my suspicion... I'll talk with upstream about the situation, because I'm not sure how PPD generator should react to such input. The simple NULL check would fix the crash, but I would prefer the complete solution for such cases. If you are in hurry, I can prepare the hot fix for your as I prepared for Andreas - it hasn't had any side effect for him as he told - please let me know if you are interested. > > The PPD for this printer is "Ricoh MP C5504 , Postscript-Ricoh 20161206 > (OpenPrinting LSB 3.2)" (which came from openprinting.org). It defines > roughly 60 media sizes, which is actually a list of 30 media listed twice: > the first time with "false setedgetoedge" and the second time with "true > setedgetoedge" and "FullBleed" in the media name. So the supported media > types in the original PPD are clearly not all borderless, and I don't know > where all the values with zero borders in the attached log are coming from. Is this the PPD you are talking about http://www.openprinting.org/download/PPD/Ricoh/PS/Ricoh-MP_C5504_PS.ppd ? It would be best if you just attach the PPD you use - then I can try to setup client-server topology, where there will be a print queue with your PPD on the server, and client will use BrowsePoll to get the remote print queue and install it locally - and hopefully reproduce the crash. Thank you for the data so far! Created attachment 1723493 [details] PPD of a printer that crashes cups-browsed Here's the PPD - it matches the one at the URL in comment 17 but with some defaults changed. It may be relevant that the CUPS server in my case is CentOS 7 running cups-1.6.3 as presumably that has its own quirks. [I don't need a hotfix as downgrading to cups-filters 1.27.3-1.fc32 doesn't crash - thanks.] Thank you for the PPD and mentioning the OS version! I can reproduce the issue now. Created attachment 1724154 [details]
ipptool output for CentOS 7 print queue
This is the output of:
$ ipptool -tv ipp://<IP>:631/printers/<print_queue_name> get-printer-attributes.test
when /usr/share/cups/ipptool/get-printer-attributes.test is modified like this:
-ATTR keyword requested-attributes all,media-col-database
+ATTR keyword requested-attributes all
The print queue is installed on CentOS 7.
Created attachment 1724155 [details]
ipptool output for Fedora 32 print queue
Created by:
$ ipptool -tv ipp://<IP>:631/printers/<print_queue_name> get-printer-attributes.test
with the default /usr/share/cups/ipptool/get-printer-attributes.test.
The server where print queue is installed is Fedora 32.
CentOS 7 cups is not capable to send media-col-database, where non-borderless medias are stored. Other sources of medias - media-size-supported, media-supported - have generated medias as borderless. I'll ask upstream how he expects PPD generator to behave. Reported upstream https://github.com/OpenPrinting/cups-filters/issues/314 FEDORA-2020-9838e6305e has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-9838e6305e FEDORA-2020-d2cae2fd30 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-d2cae2fd30 FEDORA-2020-d1a62979ee has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-d1a62979ee FEDORA-2020-9838e6305e has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-9838e6305e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-9838e6305e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-d2cae2fd30 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-d2cae2fd30` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d2cae2fd30 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-d1a62979ee has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-d1a62979ee` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d1a62979ee See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-9838e6305e has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2020-d1a62979ee has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2020-d2cae2fd30 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. |