Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Trying to print with cups a 4Gb text file fail.
texttopaps consume all the memory and is killed bye the system:
[1023082.003989] Out of memory: Kill process xxxx (texttopaps) score 955 or sacrifice child
[1023082.005120] Killed process xxxx (texttopaps) total-vm:19958848kB, anon-rss:7531872kB, file-rss:84kB, shmem-rss:0kB
/usr/lib/cups/filter/texttopaps 1 user1 "example" 1 "" sample-4Gb.txt
Of course OOM is not a software bug. Where exactly did I said that?
The problem is texttopaps that allocate memory out of control.
texttopaps should allocate memory, use-it, release-it. Like any sane program.
The issue was not present on RHEL 6. I had printed the same file multiple times with cups on RHEL6 and it worked just fine (not sure it was texttopaps cups filter involved). Printing the file does not work on RHEL 7 and it should.
The 4Gb file is a testcase for our application we develop.
I don't think the paps in RHEL7 is significantly different from RHEL6.
As you say it could be due to changes in Cups?
The cups versions in RHEL 6, 7 and Fedora are certainly quite different.
Unless texttopaps really worked in RHEL6 it might make to reassign this to cups?
Since the real computer running RHEL 6 was already scrapped, I tried to make a virtual machine using RHEL 6. Unfortunately, now I also get a crash on RHEL 6 when printing the 4GB file. I can't recall how much memory was in that computer. The virtual machine had 8Gb of memory allocated.
Still, it does not matter that much.
I think texttopaps have an issue and it should be fixed or at least an workaround should be available (other than 'don't print a file that large').
I'm afraid this is not a cups issue since I can reproduce the issue running the texttopaps standalone.
Sincerely,
Gabriel
paps isn't supposed to work with large files. to support it, most of code needs to rewritten. this isn't realistic to provide an update for existing products. for a workaround, you can remove paps package (or simply remove /usr/share/cups/mime/paps.convs file) to fall back the text filter to texttops which CUPS originally provides. this should works for this issue and as long as you don't need the internationalization support for printing.
Hope that helps.