OK, -- you where right! I have canceled all Jobs which where makt that pdf2gs failed. And now cups print as the heaven! -- No chance for the devil! This seems to me as a bug in CUPS, if pdf3gs crash if a singel document fails. Unfortunately I can not upgrade to Jessie or higher, because my Laptop is not more supported by the Kernel. (can not boot) Have a nice night/day Michelle now in Estonia On 2017-05-24 16:27:33 Bernhard Übelacker hacked into the keyboard: > 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 -- Michelle Konzack Miila ITSystems @ TDnet GNU/Linux Developer 00372-54541400
Attachment:
signature.asc
Description: Digital signature