[Xprint] Re: Hang with "-XpSpoolerType cups" - gdb traces

[Roland Mainz]

Philip Webley wrote:
> >> > Another question is definetely about xprint. When experimenting, I
> >> > decided to try option -XpSpoolerType cups. This resulted in deadlocking
> >> > of the clients. Even xphelloworld was deadlocked. The printing was done,
> >> > but I guess the socket was not closed after it, so the client was
> >> > sitting there till the server was terminated. I do have CUPS running so
> >> > I find this behaviour kind of strange. As far as I understand the
> >> > default value for this option is 'bsd:cups'
> >>[snip]
> >>
> >>I had the same sort of trouble but was able to fix it by specifying
> >>
> >>*xp-spooler-command: /usr/bin/lp -s
> >>
> >>in /etc/Xprint/C/print/attributes/printer
> >>
> >>This suppresses console output from lp, so it looks like the output
> >>(printjob ID) from lp is confusing Xprt somehow.
> >
> >
> > Weired, very weired.
> >
> > David Schweiger had a good idea - can you try to attach gdb to the Xprt
> > process and provide a stack trace of the hung Xprt, please ?
> >
> OK, I compiled xprint with -g and got these gdb traces for Xprt and
> xphelloworld (taken with the system hung). I'm not skilled with gdb but
> maybe you can make something out of them:
> 
> --snip--
[snip]
> 
> BTW, Where is stdout from lp *supposed* to go? Is it used for anything?

Per Xprint specification the output should be stored in a resource which
can be read by the client when the print job is done.
But the current Xorg implementation doesn't do that (AFAIK the HP Xprint
server implements that) - I filed
http://xprint.freedesktop.org/bugzilla/show_bug.cgi?id=790 ("Xprt may
hang when CUPS spooler sends messages to stdout") to get that
implemented.

> I tried redirecting stdout to /dev/null in SendFileToCommand() in
> xprint/src/xprint_main/xc/programs/Xserver/Xprint/attributes.c
> using the following patch - this also fixes the problem:
[snip]

Thanks for the patch! :)
I filed http://xprint.freedesktop.org/bugzilla/show_bug.cgi?id=789 for
that bug and commited a quick&dirty workaround which redicts the stdout
to stderr based on what your patch did - that fix will be part of the
009.001 maintaince release... the real solution will be implemented with
bug 790 - but that needs little bit more testing and I'd like to forward
that to the next major release ("010") ...

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)