bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #43461] A memory leak in the -[NSURLProtocol stream:handleEvent:] i


From: Sergei Golovin
Subject: [bug #43461] A memory leak in the -[NSURLProtocol stream:handleEvent:] in the case of HTTPS
Date: Thu, 23 Oct 2014 06:50:18 +0000
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0

URL:
  <http://savannah.gnu.org/bugs/?43461>

                 Summary: A memory leak in the -[NSURLProtocol
stream:handleEvent:] in the case of HTTPS
                 Project: GNUstep
            Submitted by: svg
            Submitted on: Thu 23 Oct 2014 10:50:17 AM SAMT
                Category: Base/Foundation
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

The method -[NSURLPorotocol stream:handleEvent:] has runtime conditions
when all _body's bytes are read and written and this state isn't checked:

------------------------------------------------------------
written = [this->output write: buffer maxLength: len];
if (written > 0)
  {
    if (_debug == YES)
      {
        NSLog(@"%@ wrote %d bytes: '%*.*s'", self,
        written, written, written, buffer);
      }
    len -= written;
    if (len > 0)
      {
        /* Couldn't write it all now, save and try
         * again later.
         */
        _writeData = [[NSData alloc] initWithBytes:
        buffer + written length: len];
        _writeOffset = 0;
      }
    // NOTE: here is no checking on (len == 0 and ![_body hasBytesAvailable])
  }
------------------------------------------------------------


That means that the method's logic would wait for receiving another
corresponding event (NSStreamEventHasSpaceAvailable) to execute the chunk
of code clearing the _body and setting the flag 'sent' to YES:

------------------------------------------------------------
else
  {
    [_body close];
    DESTROY(_body);
    sent = YES;
  }
------------------------------------------------------------

While it works well for HTTP because it receives enough events to leave
_body closed, in the case of HTTPS it at least can leak memory and there
is one scenario when the bug leads to hanging (for an unknown reason
the TLSHandler supplies lesser events than when no handler is involved
that is HTTP... you can observe it by inserting NSLog() at the start of
code handling the NSStreamEventHasSpaceAvailable within the method and
by changing in the attached test case the line:

------------------------------------------------------------
@"HTTPS", @"Protocol"
------------------------------------------------------------

to

------------------------------------------------------------
@"HTTP", @"Protocol"
------------------------------------------------------------

).

The hanging occurs when NSURLConnection tries to connect via HTTPS to a
resource
guarded from an unauthorized access and required some data to be uploaded
as a part of the method POST. If NSURLConnection doesn't supply
authentication
details that resource responses with '401 Unauthorized'. It may happen
when a user navigates the first time to the guarded resource (or the user may
have
cleared/lost their credentials store/cache). User's software usually shows the
user
a dialog to supply the details (e.g. a login/password form).
The NSURLConnection has the second-try capability for this situation. It
calls
it's delegate for supplying a valid authentication challenge and requests the
resource
one more time with the authentication details from that challenge.
So NSURLConnection does two request-response cycles in this case. The first
one
should end in '401'. The second cycle should end in a resulting response
whatever
it is.

The bug leaves the _body in the described above state (open and no bytes
available)
after the first cycle. So it can't read the payload (and send it to the remote
peer)
on the second stage.

REQUIRED #43460 to be applied.
The attached test case tmp.m must be placed into the directory 
Tests/base/NSURLConnection.

Also the possible fix is attached as 




    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Thu 23 Oct 2014 10:50:17 AM SAMT  Name: tmp.m  Size: 3kB   By: svg

<http://savannah.gnu.org/bugs/download.php?file_id=32314>
-------------------------------------------------------
Date: Thu 23 Oct 2014 10:50:17 AM SAMT  Name: fix_NSURLProtocol.patch  Size:
710B   By: svg

<http://savannah.gnu.org/bugs/download.php?file_id=32315>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?43461>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]