Bug#820474: cups-filters: texttopdf seg faults if comment in prettyprinted source file ends with keyword

[Brian Potkin <claremont102@gmail.com>]

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.