Control: reassign -1 src:pyppd
Control: retitle -1 pyppd: unarchiving some ppds needs large available memory
Control: tags -1 +upstream
Control: affects -1 openprinting-ppds
Le vendredi, 14 février 2020, 11.45:31 h CET sergio a écrit :
> openprinting-ppds requires too much memory, and doesn't handle this case
> correctly:
>
> % /usr/lib/cups/driver/openprinting-ppds cat
> openprinting-ppds:0/ppd/openprinting/Samsung/PXL/Samsung_M262x_282x_Series_
> PXL.ppd Traceback (most recent call last):
> File "/usr/lib/cups/driver/openprinting-ppds", line 119, in <module>
> main()
> File "/usr/lib/cups/driver/openprinting-ppds", line 95, in main
> ppd = cat(args[1])
> File "/usr/lib/cups/driver/openprinting-ppds", line 67, in cat
> ppds['ARCHIVE'] =
> BytesIO(decompress(base64.b64decode(ppds['ARCHIVE'].encode('ASCII')))) File
> "/usr/lib/cups/driver/openprinting-ppds", line 17, in decompress return
> process.communicate(value)[0]
> File "/usr/lib/python3.7/subprocess.py", line 939, in communicate
> stdout, stderr = self._communicate(input, endtime, timeout)
> File "/usr/lib/python3.7/subprocess.py", line 1711, in _communicate
> stdout = b''.join(stdout)
> MemoryError
This code is generated from pyppd, in which all PPDs are compressed in a .xz
archive, which is serialized in the /usr/lib/cups/driver/openprinting-ppds
file. This file is in fact a python self-unarchiver.
Indeed, it seems that unarchiving this PPD takes quite some amount of memory:
$ /usr/bin/time -v /usr/lib/cups/driver/openprinting-ppds cat openprinting-
ppds:0/ppd/openprinting/Samsung/PXL/Samsung_M262x_282x_Series_PXL.ppd
Command being timed: "/usr/lib/cups/driver/openprinting-ppds cat
openprinting-ppds:0/ppd/openprinting/Samsung/PXL/
Samsung_M262x_282x_Series_PXL.ppd"
User time (seconds): 2.64
System time (seconds): 1.05
Percent of CPU this job got: 13%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:27.38
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 1235052
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 311755
Voluntary context switches: 28633
Involuntary context switches: 299
Swaps: 0
File system inputs: 0
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
> Maximum resident set size (kbytes): 1235052
That's almost a Gb of memory as far as I understand it.
Till; anything upstream we could do to avoid this?
Cheers,
OdyX
