Bug 211241 - texttopaps crashes after "lpr x"
texttopaps crashes after "lpr x"
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: paps (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Akira TAGOH
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-17 20:40 EDT by Pete Zaitcev
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-13 12:53:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
error_log (75.05 KB, text/plain)
2007-01-12 22:23 EST, Pete Zaitcev
no flags Details

  None (edit)
Description Pete Zaitcev 2006-10-17 20:40:25 EDT
Description of problem:

I created a text file named "x". Running "lpr x" produced a stuck job,
and log message:
E [17/Oct/2006:17:30:52 -0700] PID 3718 (/usr/lib/cups/filter/texttopaps)
crashed on signal 11!

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

paps-0.6.6-16.fc6

How reproducible:

100% in current configuration

Steps to Reproduce:
(tentative steps)
1. Create a text file
2. lpr x
3. Run lpq to see a stuck job
  
Actual results:

Crash in texttopaps

Expected results:

Normal printing

Additional info:

Printing from PostScript-generating programs and raw printing programs
(like Mozilla) works fine.

I'm going to check where the texttopaps crashed with gdb.
Comment 1 Akira TAGOH 2006-10-18 00:53:21 EDT
to clarify this issue, if you rename x to something, does it work? also, how
about run texttopaps by hand? like

$ /usr/lib/texttopaps 1 user title 1 "" x

if it just works, can you provide more info, like your locale, and some logs
from access.log when texttopaps is invoked, which you can get with LogLevel
debug in cupsd.conf.
Comment 2 Akira TAGOH 2006-11-16 00:29:59 EST
Pete, any comments?
Comment 3 Pete Zaitcev 2007-01-12 22:18:09 EST
The problem is, running texttopaps by hand (according to your example
command above) produces an ok PostScript, so it's something related
to running it inside cups.

I looked at error_log at LogLevel debug, it had a message like this:

D [12/Jan/2007:18:59:15 -0800] [Job 158] GLib-GObject-ERROR **: file gtype.c:
line 1773 (type_class_init_Wm): assertion failed: (node->is_classed &&
node->data && node->data->class.class_size && !node->data->class.class &&
node->data->class.init_state == UNINITIALIZED)

I'll attach full log later.

So, I captured arguments and environment with a shell wrapper.
Arguments are:

/usr/lib/cups/filter/texttopaps 159 zaitcev x 1 cpi=12 lpi=7 page-bottom=86
page-left=57 page-right=57 page-top=72 scaling=100 wrap
job-uuid=urn:uuid:8a6c6d29-c83d-311d-65f3-e4d08654a0ac 
/var/spool/cups/d00159-001

Environment:

IPP_PORT=631
TMPDIR=/var/spool/cups/tmp
CUPS_FONTPATH=/usr/share/cups/fonts
CUPS_DOCROOT=/usr/share/doc/cups-1.2.7
USER=root
CUPS_SERVERROOT=/etc/cups
SOFTWARE=CUPS/1.2.7
CUPS_CACHEDIR=/var/cache/cups
DEVICE_URI=lpd://mallorn/hp
PATH=/usr/lib/cups/filter:/usr/bin:/usr/sbin:/bin:/usr/bin
CUPS_REQUESTROOT=/var/spool/cups
PWD=/
SERVER_ADMIN=root@lembas.zaitcev.lan
PPD=/etc/cups/ppd/hp.ppd
LANG=en_US
CUPS_ENCRYPTION=IfRequested
SHLVL=1
CUPS_DATADIR=/usr/share/cups
PRINTER=hp
FINAL_CONTENT_TYPE=printer/hp
RIP_MAX_CACHE=8m
CONTENT_TYPE=text/plain
CUPS_SERVER=localhost
CHARSET=utf-8
CUPS_STATEDIR=/var/run/cups
CUPS_SERVERBIN=/usr/lib/cups
_=/usr/bin/env

However, when I tried this command:

/usr/lib/cups/filter/texttopaps 159 zaitcev x 1 "cpi=12 lpi=7 page-bottom=86
page-left=57 page-right=57 page-top=72 scaling=100 wrap
job-uuid=urn:uuid:8a6c6d29-c83d-311d-65f3-e4d08654a0ac" x

the Glib error didn't occur. Instead, the program crashed with a mallog
giagnostic like this:

*** glibc detected *** /usr/local/lib/texttopaps: malloc(): memory corruption: 0
x08089130 ***
======= Backtrace: =========
/lib/libc.so.6[0x6f854b]
/lib/libc.so.6(__libc_malloc+0x7e)[0x6f9c6e]
/lib/libglib-2.0.so.0(g_malloc+0x36)[0x977626]
/lib/libglib-2.0.so.0(g_ucs4_to_utf8+0x83)[0x9941c3]
/usr/local/lib/texttopaps[0x804bbca]
/lib/libc.so.6(__libc_start_main+0xdc)[0x6a7e5c]
/usr/local/lib/texttopaps[0x8049c11]
======= Memory map: ========
00675000-0068e000 r-xp 00000000 03:01 17068      /lib/ld-2.5.90.so
0068e000-0068f000 r--p 00019000 03:01 17068      /lib/ld-2.5.90.so
....... long map
Comment 4 Pete Zaitcev 2007-01-12 22:23:47 EST
Created attachment 145516 [details]
error_log
Comment 5 Akira TAGOH 2007-01-13 03:24:01 EST
Thanks for info. I'm still thinking that this may be the content issue. so
please attach a file that you want to print out. FWIW does paps 0.6.6-17 help
you? it had a segfault fix though.
Comment 6 Pete Zaitcev 2007-01-13 12:53:18 EST
paps-0.6.6-17.fc7 fixes the issue.

And yes, I shifted the bug definition on you inadvertedly. Before, it was
a crash, and that was fixed. The log above has signal 6 (abort), not 11.

Note You need to log in before you can comment on or make changes to this bug.