tags 820474 moreinfo thanks
On Fri 08 Apr 2016 at 11:45:49 -0700, Jim Uhl wrote: > Dear Maintainer, My status is lower than that, Jim, but thanks for your detailed report and the patch. > * What led up to the situation? > > Occasionally when prettyprinting files using CUPS results in a hung > print job and no output. A recent small example occurred which > allowed creation of a small test case to demonstrate the problem. My heart drops when I see the word "occasionally"; I thought computers were predictable machines. :) > * What exactly did you do (or not do) that was effective (or > ineffective)? > > $ echo "//if" > a.c > $ lpr -p a.c > > * What was the outcome of this action? > > No output on printer, print job gets stuck in queue. I sent the file from a Wheezy client to a Wheezy server (1.0.61-5+deb8u3 for cups-filters) with 'lp -d myprinter a.c'. In the error_log I got I [10/Oct/2016:18:35:19 +0100] [Job 111] File of type application/x-csource queued by "brian". and printing was successful: D [10/Oct/2016:18:35:20 +0100] [Job 111] PID 16875 (/usr/lib/cups/filter/pdftopdf) exited with no errors. Then I sent the file with lp -d myprinter a.c -o prettyprint and got I [10/Oct/2016:18:49:39 +0100] [Job 112] File of type application/x-csource queued by "brian". D [10/Oct/2016:18:49:40 +0100] [Job 112] PID 20220 (/usr/lib/cups/filter/texttopdf) crashed on signal 11. E [10/Oct/2016:18:49:40 +0100] [Job 112] Can't detect file type The same printer was set up on an unstable machine with cups-filters 1.11.4-1 and a.c sent to it using the previous command. The job printed successfully. > * What outcome did you expect instead? > > Pretty printed version of the above one line file. This does happen on the present unstable. > Some digging in the cups log files revealed that > /usr/lib/cups/filter/texttopdf seg faults. The error can be > reproduced direclty with the following command: > > $ echo "//if" | CONTENT_TYPE=application/x-csource > /usr/lib/cups/filter/texttopdf 123 username a.c 1 "prettyprint" > a.c.pdf This completes successfully for me on unstable. As does /usr/sbin/cupsfilter -o prettyprint a.c > a,c.pdf > Debugging with gdb, the local array "names", having 3 elements, in > filters/texttopdf.c:write_font_str is being indexed with a value of 3 > because both bold and italic are active at the newline. > > In filters/textcommon.c there are four places that look up keywords, > only one ensures that italics are not active when searching for a > keyword: > > if (!(attr & ATTR_ITALIC) && > bsearch(&keyptr, Keywords, NumKeywords, sizeof(char *), > compare_keywords)) > > The attached patch adds the attribute check to the other three > searches which prevents the seg fault - that is, texttopdf runs to > completion and generates a printable PDF. My skills with gdb are non-existent; as is my ability to analyse and critique your explanation. Personally, I would close this report because the issue is apparently fixed with unstable's cups-filters 1.11.4-1. You could test in that environment and let us know where you want to go from there. Regards, Brian.
