-
Notifications
You must be signed in to change notification settings - Fork 457
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ipptool hangs in http_read despite timeout (-T 10) #4515
Comments
CUPS.org User: tometzky I couldn't attach a core file directly to this report. Please download from http:https://prhn.ato.waw.pl/~tometzky/tmp/core.10765.xz |
CUPS.org User: tometzky This process did not even react to TERM signal. I had to use 'kill -9' to kill it. |
CUPS.org User: mike ipptool catches SIGTERM when timeouts are in use - a second SIGTERM will kill it. It should not be possible for libcups to hang like this - when timeouts are set the read should only occur if input is available. Investigating. |
CUPS.org User: mike Fixed in Subversion repository. |
"str4515.patch": Index: cups/ipp.c--- cups/ipp.c (revision 12463)
if ((bytes = httpRead2(http, (char *)buffer, length - (size_t)tbytes)) < 0) |
Version: 2.0.0
CUPS.org User: tometzky
I'm using ipptool (really ipptool-static) on Linux (CentOS6 x86_64, manually compiled ipptool) to check printer queue (Canon iR3225) like this:
DEVICE_URI="ipp:https://printerhostname/ipp"
IPPTOOL="ipptool"
IPPTOOL_GET_QUEUED_JOB_COUNT='
{
NAME "Get queued job count using Get-Printer-Attributes"
OPERATION Get-Printer-Attributes
}
'
$IPPTOOL -c -T 10 "$DEVICE_URI" /dev/stdin <<< "$IPPTOOL_GET_QUEUED_JOB_COUNT"
queued-job-count
0
But despite using "-T 10" ipptool process hanged for 18 hours in http_read function. Even restarting a printer did not help as ipptool does not use TCP SO_KEEPALIVE.
Please enable SO_KEEPALIVE for ipptool connections by default or at least add an option to enable it.
Here's a backtrace from hanging process:
#0 0x00007f0236302b12 in __libc_recv (fd=, buf=0x7f02387601e1, n=8, flags=)
#1 0x00007f023674ea6f in recv (http=0x7f023875bab0, buffer=0x7f02387601e1 "\003", length=8)
#2 http_read (http=0x7f023875bab0, buffer=0x7f02387601e1 "\003", length=8) at http.c:4079
#3 0x00007f023674f571 in httpRead2 (http=0x7f023875bab0, buffer=0x7f02387601e1 "\003", length=)
#4 0x00007f023675891f in ipp_read_http (http=0x7f023875bab0, buffer=, length=8) at ipp.c:6834
#5 0x00007f02367592bd in ippReadIO (src=0x7f023875bab0, cb=0x7f02367588b0 <ipp_read_http>, blocking=1,
#6 0x00007f023675f73b in cupsGetResponse (http=0x7f023875bab0, resource=) at request.c:402
#7 0x00007f0236744753 in do_tests (outfile=, vars=0x7fff05dbf320,
#8 0x00007f02367494f4 in main (argc=6, argv=0x7fff05dc0ab8) at ipptool.c:670
I'm attaching a compressed core file (from CentOS 6.6 x86_64 with all updates until today) - it may help with debugging this.
The text was updated successfully, but these errors were encountered: