Hello Michelle Konzack, not being maintainer I was just curious about this problem, so I tried to reproduce ...
- Installed a amd64 Wheezy VM - Inside installed cups-pdf printer. - Changed in /etc/cups/cupsd.conf from "LogLevel warn" to "LogLevel debug" Then following commands led not to the same error: lp Diplomarbeit_Analyse_zweier_Fronthubwerke_Ebetshuber.pdf Then - deleted the virtual PDF printer. - Tried to add a Brother MFC-J5910 printer, first by extracting the ppd from mfcj5910dwcupswrapper-3.0.0-1.i386.deb [3], later installing it completely. (pointing to a non-existing IP) Then again I got no such crash: [Job 1205] Started filter gs (PID 13883) PID 13859 (/usr/lib/cups/filter/pdftopdf) exited with no errors. [Job 1205] Started post-processing (PID 13884) [Job 1205] Started filter pstops (PID 13885) [Job 1205] prtGeneralCurrentLocalization type is 0, expected 2! [Job 1205] backendWaitLoop(snmp_fd=5, addr=0x7f38db622a38, side_cb=0x7f38da352460) [Job 1205] Inserted workaround PostScript code for Brother printers [Job 1205] Page = 595x842; 9,9 to 586,833 [Job 1205] slow_collate=0, slow_duplex=0, slow_order=0 [Job 1205] Before copy_comments - %!PS-Adobe-3.0 [Job 1205] %!PS-Adobe-3.0 [Job 1205] %%BoundingBox: 0 0 595 842 [Job 1205] %%Creator: GPL Ghostscript 905 (ps2write) [Job 1205] %%LanguageLevel: 2 [Job 1205] %%CreationDate: D:20170524150906+02'00' [Job 1205] %%Pages: 103 [Job 1205] %%EndComments ... [Job 1205] PID 13883 (gs) exited with no errors. (PIDs and Job changed for better comparing.) Therefore there is probably only little left that can be done remotely. - Does feeding the PDF from command line by the lp command lead to the crash on your system? - Are there any print jobs before in the queue waiting to be processed? (Job 1183 to Job 1204 in your logs.) You can check them via http://localhost:631 - Is the problem also visible on a fresh installation? - You really used the printer driver in [3]? - You probably can enable system wide core dumps by enabling in limits.conf [1] or probably corekeeper from wheezy-backports can do. Then inspecting such a core by: gdb /usr/bin/gs --core /path/to/core bt - If that is not working, probably attaching gdb cupsd itself can lead to something (time consuming), with correctly following the processes by the right combinations of "set follow-fork-mode parent" / "set follow-fork-mode child". But probably the crash in gs is just a consequence of the data delivered by the other filters before ... Kind regards, Bernhard ├─cupsd─┬─brother_lpdwrap───cat │ ├─pdftops─┬─gs │ │ ├─pdftops │ │ └─pstops │ └─socket [1] https://www.akadia.com/services/ora_enable_core.html [2] https://packages.debian.org/sid/corekeeper [3] http://support.brother.com/g/b/downloadend.aspx?c=de&lang=de&prod=mfcj5910dw_all&os=128&dlid=dlf006600_000&flang=4&type3=561&dlang=true#pane6
