Bug 216296

Created attachment 141569 [details]
The attached file steadfastly refuses to print

I have removed all embedded TABs from the file which I attached and substituted
SPACEs and the file now prints. So the problem is definitely content dependent.
I notice that if I print a piece of Pascal code it is printed using one font,
whereas if I print a piece of C code it is printed using a different font. Could
the embedded TABs be causing the driver to try and use a font which it is unable
to load? I wonder if there is an obscure message buried in one of the files in
/var/log. Just a thought...

I'd like to get some debugging information.  Please do the following, as root.

Edit /etc/cups/cupsd.conf and change the 'LogLevel' line to read:

  LogLevel debug2

Stop CUPS:

  /sbin/service cups stop

Clear out the error log:

  >/var/log/cups/error_log

Then start CUPS again:

  /sbin/service cups start

Now print the file again, and when it fails to print please attach
/var/log/cups/error_log.  Thanks.

Tim

I'm unable to attach /var/log/cups/error_log as I get the following error
message each time I try.

Chris


Software error:

Malformed multipart POST

For help, please send mail to the webmaster (bugzilla-owner), giving
this error message and the time and date of the error.
Software error:

Unknown error
Compilation failed in require at /var/www/html/bugzilla/attachment.cgi line 43.

For help, please send mail to the webmaster (bugzilla-owner), giving
this error message and the time and date of the error.

Created attachment 141651 [details]
cups error log as requested

Okay, this is the problem:

E [20/Nov/2006:13:01:07 +0000] PID 2625 (/usr/lib/cups/filter/texttopaps)
crashed on signal 11!

Could you attach the PPD file for that queue please? (Sorry about the attachment
problems you had earlier but it looks like they're resolved now..)

Created attachment 141669 [details]
cups ppd file for HP950C duplex printer as requested

How to reproduce:
1. /usr/lib/cups/filter/texttopaps 1 me '' 1 'cpi=12' <adfs.c

Backtrace:
#0  0x00000039b0a6ed4a in _int_malloc () from /lib64/libc.so.6
#1  0x00000039b0a7089d in malloc () from /lib64/libc.so.6
#2  0x00000039b2233d9b in g_malloc () from /lib64/libglib-2.0.so.0
#3  0x00000039b224ee4c in g_ucs4_to_utf8 () from /lib64/libglib-2.0.so.0
#4  0x00000000004043f8 in main (argc=7, argv=0x7fff1c593ce8) at paps.c:745
745                       newtext = g_ucs4_to_utf8 ((const gunichar *)wnewtext,
i, NULL, NULL, NULL);

[root@home ~]# /usr/lib/cups/filter/texttopaps 1 me '' 1 'cpi=12'
</home/chris/adfs/adfs.c
Segmentation fault
[root@home ~]# 

tagoh: I think what's happening is that wcswidth(wtext) [line 724] is
-1 because it contains a '\t' (non-printable character).  Then the loop at line
736 overflows the buffer.  We need to handle:

(a) tab characters specially (perhaps convert to spaces before processing)

(b) other non-printable characters as width 1 (say)

and also that loops needs to restrict i < para->length (or whatever the actual
buffer limit is).

will be fixed in 0.6.6-17.fc6.

paps-0.6.6-17.fc6 has been pushed for fc6, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

Updated my FC6 installation using yum this morning. This installed
paps-0.6.6-17.fc6 All the files I was having trouble with now print perfectly.
Many thanks.