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

Reply via email to