Bug 1677534 - texttopaps OOMs with 4GB text file!
Summary: texttopaps OOMs with 4GB text file!
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: paps
Version: rawhide
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Akira TAGOH
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1635160
TreeView+ depends on / blocked
 
Reported: 2019-02-15 07:39 UTC by Jens Petersen
Modified: 2021-06-28 06:06 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1635160
Environment:
Last Closed:
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jens Petersen 2019-02-15 07:39:22 UTC
(Cloned from a RHEL7 report)

+++ This bug was initially created as a clone of Bug #1635160 +++

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

--- Additional comment from Akira TAGOH on 2018-10-03 11:54:48 SGT ---

Hmm, that log says it all. I don't think OOM is a software bug.

--- Additional comment from GV on 2018-10-03 13:00:48 SGT ---

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.

--- Additional comment from Jens Petersen on 2018-10-18 17:49:35 SGT ---

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?

--- Additional comment from GV on 2018-10-25 18:29:46 SGT ---

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

--- Additional comment from Akira TAGOH on 2018-11-16 17:59:04 SGT ---

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.

--- Additional comment from GV on 2018-12-07 14:03:33 SGT ---

It helps. Thank you!

Comment 1 Ben Cotton 2019-08-13 17:05:51 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

Comment 2 Ben Cotton 2019-08-13 19:34:55 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

Comment 3 Ben Cotton 2020-08-11 15:20:17 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.


Note You need to log in before you can comment on or make changes to this bug.