reassign 377640 libcupsys2 found 377640 1.2.2-2 kthxbye On Fri, Sep 22, 2006 at 07:03:14 -0400, Brice Goglin wrote:
> #5 0xb758e3bc in httpRead2 (http=0x80b4db8, buffer=0xb52b719d
> "%-·´q+µ,[Z·\001v*·", length=8) at http.c:1166
> #6 0xb75949f3 in ipp_read_http (http=0x80b4db8, buffer=0xb52b719d
> "%-·´q+µ,[Z·\001v*·", length=8)
> at ipp.c:2759
> #7 0xb759454e in ippReadIO (src=0x80b4db8, cb=0xb7594860 <ipp_read_http>,
> blocking=1, parent=0x0,
> ipp=0x80bb9f8) at ipp.c:1054
> #8 0xb759475d in ippRead (http=0xb75a9918, ipp=0x80bb9f8) at ipp.c:991
> No locals.
> #9 0xb759e792 in cupsDoFileRequest (http=0x80b4db8, request=0x80bb738,
> resource=0x8075c50 "/", filename=0x0)
> at request.c:346
I think this is the relevant part.
If recv() returns 0 to httpRead2(), it sets http->error to EPIPE and
returns 0, which is propagated by ipp_read_http().
The call to ipp_read_http() at ipp.c:1054 is trying to read a header:
if ((n = (*cb)(src, buffer, 8)) < 8)
{
DEBUG_printf(("ippReadIO: Unable to read header (%d bytes
read)!\n", n));
return (n == 0 ? IPP_IDLE : IPP_ERROR);
}
In this case, it returns IPP_IDLE, which is IMO wrong because a return
value of 0 means an EOF condition, not that "Nothing is happening".
The relevant part in cupsDoFileRequest() looks like this:
while ((state = ippRead(http, response)) != IPP_DATA)
if (state == IPP_ERROR)
{
/*
* Delete the response...
*/
DEBUG_puts("IPP read error!");
ippDelete(response);
response = NULL;
_cupsSetError(IPP_SERVICE_UNAVAILABLE, strerror(errno));
break;
}
This means that libcupsys enters an infinite loop and doesn't detect the
EOF condition (nothing seems to check http->error).
I'm therefore reassigning this bug to libcupsys2.
Cheers,
Julien
signature.asc
Description: Digital signature
