Comment 4 for bug 267903

I'm sorry that the information provided so far ist too thin.

It seems that, if the print-job's media size differs from the printer's default media-size, rastertoqpdl segfaults.
My printer is set to A4 media, while all KDE programs use "Letter" by default. This probably has caused the crashes I observed earlier.
However, even if rastertoqpdl doesn't crash, the printouts still are completely black.

I've attached a small LaTeX document and the resulting input.ps/input.pdf files to demonstrate the problem. The document size is set to A4 media.
# ML-2510_(Ubuntu) is using Splix (rastertoqpdl):
# no crash/ black printout; see bug267903.tar.gz/target_media_a4/*
lp -d "ML-2510_(Ubuntu)" -o media=a4 input.ps

# segfault; see bug267903.tar.gz/target_media_letter/*
lp -d "ML-2510_(Ubuntu)" -o media=letter input.ps

As already mentioned, the Samsung-driver works fine in both cases. Unfortunatelly, I don't know how to efficiently debug a CUPS filter. I noticed, however, that everything seems to get piped through /usr/lib/cups/filter/pdftoraster before it is fed to rastertoqpdl. Therefore I've created a small wrapper script around pdftoraster which records command-line arguments, environment variables and the output from the "real" pdftoraster, which is then used as input to a "stand-alone" (i.e. not started by CUPS) rastertoqpdl with gdb or valgrind attached. If there is a better way to do this, please let me know.

The following debugging packages are installed:
cups-dbg libc6-dbg libcomerr2-dbg libgcc1-dbg libgcrypt11-dbg libgnutls26-dbg libgpg-error0-dbgsym libjpeg62-dbgsym libkeyutils1-dbgsym libkrb53-dbgsym libpng12-0-dbgsym libstdc++6-4.3-dbg libtasn1-3-dbg libtiff4-dbgsym splix-dbgsym zlib1g-dbg
Yet, gdb still complains about missing debugging symbols. I hope the backtraces help to isolate the problem nevertheless.

Please feel free to ask, if you need further information.