Bug#377640: gnome-cups-manager: takes 100% CPU without any reason

Julien Cristau jcristau at liafa.jussieu.fr
Fri Sep 22 15:46:53 UTC 2006


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20060922/5d775e3d/attachment.pgp


More information about the Pkg-gnome-maintainers mailing list