Bug 211241

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.

Pete, any comments?

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.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

Created attachment 145516 [details]
error_log

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.

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.