Issue 3772: Distributed reliability test failures with NewHTTP
http://code.google.com/p/chromium/issues/detail?id=3772
Comment #4 by [EMAIL PROTECTED]:
[update with some findings and speculation; nothing conclusive so don't
obligated to read]:
The dumps I looked at were fairly consistent, being access violations
reading bad instruction pointer. EIP looks like it could be a
heap address, which often implies stack smashing, or a bad object instance
(specifically invoking a virtual method on it).
The callstack reported by the crash server is a bit misleading -- it stops
its analysis after DoReadHeadersComplete()'s frame. It
seems there is actually a return address to DidReadResponseHeaders()
following this, and then an unknown frame (92 bytes of data I
have not investigated yet).
I suspect our problem lies within DidReadResponseHeaders(). This is
actually a fair amount of surface area, including at least:
- header parsing
- vary data initialization
+ md5 accumulation
- reading SSL socket info
At a glance I also spotted at least one virtual function call:
if (using_ssl_ && !establishing_tunnel_) {
SSLClientSocket* ssl_socket =
reinterpret_cast<SSLClientSocket*>(connection_.socket());
ssl_socket->GetSSLInfo(&response_.ssl_info);
}
Dunno about this, but suppose if |using_ssl_| were true when it should be
false, then invoking the virtual GetSSLInfo() could blow
things up. (I don't actually have data suggesting this, other than an
aversion to reinterpret_cast).
A final observation, is that the error looks to be reproducible for the
same inputs. While I was unable to reproduce locally, many of
the crashdumps share the same value of |result| for crashes on the same
site. (|result| in this case is the number of bytes that were
read). For example the loads of passport.net seem to die with result=1510.
This is encouraging -- it implies that the crash may be reproducible with
the same data. In which case if we were testing with the
fastnet proxy (which chrome-bot uses), it might reproduce.
I think the easiest thing to do now is do some runs of chrome-bot to
collect full-memory dumps.
Once we have the full-memory dumps, the problem may become obvious
(specifically I want to see what EIP's bogus value corresponds with on the
heap, if anything).
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Chromium-bugs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/chromium-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---
