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.
Bug 1635160 - texttopaps OOMs with 4GB text file!
Summary: texttopaps OOMs with 4GB text file!
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: paps
Version: 7.5
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Akira TAGOH
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On: 1677534
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-10-02 08:54 UTC by GV
Modified: 2019-02-15 07:40 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1677534 (view as bug list)
Environment:
Last Closed: 2019-02-15 07:40:50 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description GV 2018-10-02 08:54:32 UTC 
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
Comment 2 Akira TAGOH 2018-10-03 03:54:48 UTC 
Hmm, that log says it all. I don't think OOM is a software bug.
Comment 3 GV 2018-10-03 05:00:48 UTC 
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.
Comment 4 Jens Petersen 2018-10-18 09:49:35 UTC 
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?
Comment 5 GV 2018-10-25 10:29:46 UTC 
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
Comment 6 Akira TAGOH 2018-11-16 09:59:04 UTC 
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.
Comment 7 GV 2018-12-07 06:03:33 UTC 
It helps. Thank you!
Comment 9 Jens Petersen 2019-02-15 07:40:50 UTC 
Okay I moved the bug to Fedora.
Note You need to log in before you can comment on or make changes to this bug.