Bug 216296

Summary: Success of lpr seems to be file content dependent.
Product: [Fedora] Fedora Reporter: Chris Smith <chris>
Component: papsAssignee: Akira TAGOH <tagoh>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6CC: twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: athlon   
OS: Linux   
Fixed In Version: 0.6.6-17.fc6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-12-05 02:27:24 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 207681    
Description Flags
The attached file steadfastly refuses to print
cups error log as requested
cups ppd file for HP950C duplex printer as requested none

Description Chris Smith 2006-11-18 23:06:58 UTC
Description of problem: After update from FC5 to FC6 printing via lpr seems to
be file content dependent. Some files print OK others are queued but fail to
print. Printer is HP DeskJet 950C attached to JetDirect 300X on network.
The attached file will not print whereas the header file associated with it
prints. Experiments with another file (not attached) showed that replacing
embeded TABs with SPACEs enabled file to print.

Version-Release number of selected component (if applicable):

How reproducible: Totally!

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 Chris Smith 2006-11-18 23:06:59 UTC
Created attachment 141569 [details]
The attached file steadfastly refuses to print

Comment 2 Chris Smith 2006-11-20 10:33:01 UTC
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...

Comment 3 Tim Waugh 2006-11-20 12:35:28 UTC
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:


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.

Comment 4 Chris Smith 2006-11-20 13:28:41 UTC

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


Software error:

Malformed multipart POST

For help, please send mail to the webmaster (bugzilla-owner@redhat.com), 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@redhat.com), giving
this error message and the time and date of the error.

Comment 5 Chris Smith 2006-11-20 14:01:39 UTC
Created attachment 141651 [details]
cups error log as requested

Comment 6 Tim Waugh 2006-11-20 16:48:32 UTC
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..)

Comment 7 Chris Smith 2006-11-20 17:03:20 UTC
Created attachment 141669 [details]
cups ppd file for HP950C duplex printer as requested

Comment 8 Tim Waugh 2006-11-20 17:19:24 UTC
How to reproduce:
1. /usr/lib/cups/filter/texttopaps 1 me '' 1 'cpi=12' <adfs.c

#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,

Comment 9 Chris Smith 2006-11-20 17:45:42 UTC

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

Comment 10 Tim Waugh 2006-11-20 18:14:03 UTC
tagoh@redhat.com: 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).

Comment 11 Akira TAGOH 2006-12-04 12:06:34 UTC
will be fixed in 0.6.6-17.fc6.

Comment 12 Fedora Update System 2006-12-04 14:30:56 UTC
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.

Comment 13 Chris Smith 2006-12-05 08:30:28 UTC
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.