search

apple / cups

Apple CUPS Sources
https://www.cups.org
Apache License 2.0
1.94k stars 464 forks source link

USB process hangs on end-of-file, making further printing impossible #3318

Closed michaelrsweet closed 15 years ago

michaelrsweet commented 15 years ago

Version: 1.4-current CUPS.org User: till.kamppeter

The original bug report

http://www.cups.org/str.php?L3315

got closed as fixed, but the changes in the attached patch did not actually fix the problem. The infinite loop was not caused by the side channel being read after the filter having gotten closed, but it was cause by the polls on the data channel getting answered with POLLHUP both at arbitrary times during data transfer and also after the end of the data transfer. Data was tried to be read only when a poll was answered with POLLIN and this answer does not appear any more when all data is transfered. Then the answer is always POLLHUP which causes the infinite loop. Now we try to read data also on POLLHUP answers and so we can determine the end of the stream.

New patch is attached.

michaelrsweet commented 15 years ago

CUPS.org User: mike

A similar fix was already committed to the repository (for all backends) after the change for STR #3315.

michaelrsweet commented 15 years ago

CUPS.org User: mike

From Till:

Your additional fixes in rev 8806 and 8807 do definitely not fix the

infinite loop problem for me. If I apply the patch which I have attached to STR #3318, the problem disappears for me.

Reopening until we resolve what is going on...

michaelrsweet commented 15 years ago

CUPS.org User: mike

OK, Till - the current trunk and branch-1.4 code is 99% identical to what your patch did except for the POLLHUP in the print_fd check and whether we still log a bad side channel read. Since POLLHUP cannot be returned in revents by itself (it will also always have POLLIN set because that is what we ask for), the change for the print_fd monitoring must not be necessary. The logging of a bad side-channel read is likewise not necessary.

So, please re-test with a clean build of trunk or branch-1.4 - if you still see a problem, attach a full debug error_log file from a job that is doing this along with the PPD file you are using for the printer.

michaelrsweet commented 15 years ago

CUPS.org User: sjakub

My bug request #3326 has been closed so I can write there, but it is related to this one. Why should I contact my distribution about this? (I already have and was told to contact upstream). What does the distribution have to do with that? The cups is not patched in any way except for the patch from here (#3318), so I have no idea how is this a distribution-specific issue.

michaelrsweet commented 15 years ago

CUPS.org User: mike

Jakub,

You are using a driver that is not part of CUPS with a patched CUPS; we can't (and won't) try to support that configuration.

I'm still waiting on feedback from Till.

michaelrsweet commented 15 years ago

CUPS.org User: till.kamppeter

If I take the source of the USB backend from HEAD, uab-unix.c and usb.c are identical with what we are using at Ubuntu. usb-libusb.c has only the following difference (hunks on the SVN ID removed):

--- /home/till/ubuntu/cups/bzr/build-area/cups-1.4.0/backend/usb-libusb.c 2009-09-02 18:37:32.000000000 +0200 +++ backend/usb-libusb.c 2009-09-11 21:19:19.000000000 +0200 @@ -158,7 +158,7 @@

 while (poll(pfds, 2, -1) > 0)
 {

The version from HEAD (no " + POLLHUP") produces the infinite loop for me (job stays in queue and blocks next job), the version with the Ubuntu patch (with " + POLLHUP") works correctly (backend closes and queue gets free for next job).

michaelrsweet commented 15 years ago

CUPS.org User: mike

Fixed in Subversion repository.

The final patch uses (POLLIN | POLLHUP) (instead of +), for both the print_fd and side-channel fd.

michaelrsweet commented 15 years ago

"str3318.patch":

Index: backend/usb-libusb.c

--- backend/usb-libusb.c (revision 8809) +++ backend/usb-libusb.c (working copy) @@ -158,7 +158,16 @@

 while (poll(pfds, 2, -1) > 0)
 {