[cups.bugs] [MOD] STR #3381: cups-polld wedged at 100% processor usage (reproduced)

[Maciej Bliziński]

DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

The main spin happens around the two lines of code:

while (status == HTTP_CONTINUE)
  status = httpUpdate(http);

httpUpdate always returns HTTP_CONTINUE, and the loop is infinite.

Current findings: there is a call to http_read_ssl in http.c:1058. It
returns number -10, which gets assigned to the 'bytes' variable. A
negative number denotes an error (as I understood that from the code). The
'errno' variable is still at zero, as initialized at the beginning
ofhttpGets (). I'm guessing that it should have been set to a non-zero
value. It's not equal to EINTR or EAGAIN. It's also not different from
http->error (which is also equal to zero). In result,httpGets returns
NULL.

httpUpdate examines http->error to see if there were any problems.
http->error is 0, so httpUpdate returns HTTP_CONTINUE and loop closes.

httpGets is expecting errno to be set upon the return from
gnutls_record_recv. However, gnutls_record_recv uses different semantics;
it doesn't rely on returning -1 and setting the errno; instead, it returns
an error code as defined in includes/gnutls/gnutls.h. In this case, number
-10 corresponds to GNUTLS_E_INVALID_SESSION.

errno is being set to zero in httpGets(), near the beginning. I have a
theory that in most of the cases, the gnutls-powered code would work,
because gnutls would fail for reasons related to recv(), and recv() sets
errno. Perhaps in the case of GNUTLS_E_INVALID_SESSION, the cause for the
error is not recv-related, which makes it a special case.

A better way of handling gnutls errors would be to rely on the values
returned by gnutls_record_recv rather than errno, since setting errno is
not part of gnutls' API.

Link: http://www.cups.org/str.php?L3381
Version: 1.4.0