Fix a crash in the FileStream::Context::Read code path where we were invoking a NULL callback.

net/base/file_stream_context_win.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "net/base/file_stream_context.h"
 
 #include <windows.h>
 
 #include "base/files/file_path.h"
 #include "base/logging.h"
@@ skipping 156 matching lines @@
     IncrementOffset(&io_context_.overlapped, bytes_read);
   }
 
   if (async_read_initiated_)
     io_complete_for_read_received_ = true;
 
   InvokeUserCallback();
 }
 
 void FileStream::Context::InvokeUserCallback() {
+  if (callback_.is_null())
+    return;
   // For an asynchonous Read operation don't invoke the user callback until
   // we receive the IO completion notification and the asynchronous Read
   // completion notification.
   if (async_read_initiated_) {
     if (!io_complete_for_read_received_ || !async_read_completed_)
       return;
     async_read_initiated_ = false;
     io_complete_for_read_received_ = false;
     async_read_completed_ = false;
     async_in_progress_ = false;
   }
   CompletionCallback temp_callback = callback_;
   callback_.Reset();
   scoped_refptr<IOBuffer> temp_buf = in_flight_buf_;
   in_flight_buf_ = NULL;
   temp_callback.Run(result_);
 }
 
 // static
 void FileStream::Context::ReadAsync(
     FileStream::Context* context,
     HANDLE file,
     scoped_refptr<net::IOBuffer> buf,
     int buf_len,
     OVERLAPPED* overlapped,
     scoped_refptr<base::MessageLoopProxy> origin_thread_loop) {
   DWORD bytes_read = 0;
   BOOL ret = ::ReadFile(file, buf->data(), buf_len, &bytes_read, overlapped);
   origin_thread_loop->PostTask(
       FROM_HERE, base::Bind(&FileStream::Context::ReadAsyncResult,

[rvargas (doing something else), 2015/02/12 22:24:54]

ret = TRUE + a completion callback is the expected behavior. I believe this
should be changes to explicitly communicate ret to the other thread because we
should not be accessing anything before looking at the return value of the call
(and that includes read_bytes, but also last error).

I should have mentioned that on the last review, but I expected that code to
last only one day in trunk before writing another CL based on the results (it
was a quick test). BTW, I'm seriously inclined to say that the DrMemory report
was bogus, but I don't really mind having to wait for two signals.

[ananta, 2015/02/12 22:47:59]

Done.

                             base::Unretained(context), ret ? bytes_read : 0,
                             ret ? 0 : ::GetLastError()));
 }
 
 void FileStream::Context::ReadAsyncResult(DWORD bytes_read, DWORD os_error) {
   if (!os_error)
     result_ = bytes_read;
 
   IOResult error = IOResult::FromOSError(os_error);
   if (error.os_error == ERROR_HANDLE_EOF) {
     // Report EOF by returning 0 bytes read.
     OnIOCompleted(&io_context_, 0, error.os_error);
   } else if (error.os_error != ERROR_IO_PENDING) {
     // We don't need to inform the caller about ERROR_PENDING_IO as that was
     // already done when the ReadFile call was queued to the worker pool.
     if (error.os_error) {
       LOG(WARNING) << "ReadFile failed: " << error.os_error;
       OnIOCompleted(&io_context_, 0, error.os_error);
     }
   }
   async_read_completed_ = true;
   InvokeUserCallback();
 }
 
 }  // namespace net