[SPDY] Use WeakPtr<HttpServerProperties> instead of raw pointers

[SPDY] Use WeakPtr<HttpServerProperties> instead of raw pointers

This will let us better track down what is causing SpdySessions to be
accessing them after they're destroyed, since we'll have crash reports
instead of just the SyzyASAN reports.

Also use scoped_ptr<HttpServerProperties> when appropriate.

BUG=236451
[email protected], [email protected], [email protected], [email protected]

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=212466

[akalin, 2013-07-18 05:18:04]

+rtenneti for review

[ramant (doing other things), 2013-07-18 06:05:18]

lgtm

[commit-bot: I haz the power, 2013-07-18 11:10:54]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/19731002/1

[commit-bot: I haz the power, 2013-07-18 11:24:02]

Retried try job too often on chromium_presubmit for step(s) presubmit
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=chromium_p...

[akalin, 2013-07-18 17:50:28]

+wez for remoting
+jochen for content/shell
+simonjam for content/browser/loader
+ajwong for chrome/service and chrome/browser/profiles
+eroman for chrome/browser/ui/webui/net_internals
+jam for chrome/browser

I'll probably TBR one or more of the above soon, since the changes are
mechanical

[James Simonsen, 2013-07-18 18:12:33]

lgtm

[awong, 2013-07-18 18:13:56]

https://codereview.chromium.org/19731002/diff/1/chrome/browser/net/connection...
File chrome/browser/net/connection_tester.cc (right):

https://codereview.chromium.org/19731002/diff/1/chrome/browser/net/connection...
chrome/browser/net/connection_tester.cc:118: new
net::HttpServerPropertiesImpl));
nit:new net::HttpServletPropertiesImpl()

https://codereview.chromium.org/19731002/diff/1/chrome/browser/net/http_serve...
File chrome/browser/net/http_server_properties_manager.cc (right):

https://codereview.chromium.org/19731002/diff/1/chrome/browser/net/http_serve...
chrome/browser/net/http_server_properties_manager.cc:69:
HttpServerPropertiesManager::~HttpServerPropertiesManager() {
Reset the io_weak_ptr_factory_ first for WeakPtr<> hygiene?

As usual though, this concerns me because this class can be subclassed and since
we vend WeakPtrs from this factory in the public API, there's no way to
guarantee someone isn't going to use one when this object is partially
destructed...is this something you guys are deciding not to worry about?

[Wez, 2013-07-18 18:53:57]

https://codereview.chromium.org/19731002/diff/1/remoting/base/url_request_con...
File remoting/base/url_request_context.cc (right):

https://codereview.chromium.org/19731002/diff/1/remoting/base/url_request_con...
remoting/base/url_request_context.cc:94: scoped_ptr<net::HttpServerProperties>(
I expect I'm being dense, but why is this required?

[akalin, 2013-07-18 20:34:29]

PTAL

https://codereview.chromium.org/19731002/diff/1/chrome/browser/net/connection...
File chrome/browser/net/connection_tester.cc (right):

https://codereview.chromium.org/19731002/diff/1/chrome/browser/net/connection...
chrome/browser/net/connection_tester.cc:118: new
net::HttpServerPropertiesImpl));
On 2013/07/18 18:13:57, awong wrote:
> nit:new net::HttpServletPropertiesImpl()

Done, fixed everywhere else.

https://codereview.chromium.org/19731002/diff/1/chrome/browser/net/http_serve...
File chrome/browser/net/http_server_properties_manager.cc (right):

https://codereview.chromium.org/19731002/diff/1/chrome/browser/net/http_serve...
chrome/browser/net/http_server_properties_manager.cc:69:
HttpServerPropertiesManager::~HttpServerPropertiesManager() {
On 2013/07/18 18:13:57, awong wrote:
> Reset the io_weak_ptr_factory_ first for WeakPtr<> hygiene?
> 
> As usual though, this concerns me because this class can be subclassed and
since
> we vend WeakPtrs from this factory in the public API, there's no way to
> guarantee someone isn't going to use one when this object is partially
> destructed...is this something you guys are deciding not to worry about?

Done.

I don't think implementations of HttpServerProperties are intended to be
subclassed further. In particular, this implementation composes its underlying
HttpServerPropertiesImpl instead of inheriting from it.

I'm not completely happy with adding a GetWeakPtr() function, but I don't think
stuff will get complex enough that we need to worry about weak ptrs and partial
destruction.

https://codereview.chromium.org/19731002/diff/1/remoting/base/url_request_con...
File remoting/base/url_request_context.cc (right):

https://codereview.chromium.org/19731002/diff/1/remoting/base/url_request_con...
remoting/base/url_request_context.cc:94: scoped_ptr<net::HttpServerProperties>(
On 2013/07/18 18:53:57, Wez wrote:
> I expect I'm being dense, but why is this required?

I changed the set_http_server_properties function to take a scoped_ptr<> instead
of a raw pointer to better express the fact that it takes ownership. So this
requires all callers to pass in scoped_ptrs.

[Wez, 2013-07-18 21:03:37]

https://codereview.chromium.org/19731002/diff/1/remoting/base/url_request_con...
File remoting/base/url_request_context.cc (right):

https://codereview.chromium.org/19731002/diff/1/remoting/base/url_request_con...
remoting/base/url_request_context.cc:94: scoped_ptr<net::HttpServerProperties>(
On 2013/07/18 20:34:29, akalin wrote:
> On 2013/07/18 18:53:57, Wez wrote:
> > I expect I'm being dense, but why is this required?
> 
> I changed the set_http_server_properties function to take a scoped_ptr<>
instead
> of a raw pointer to better express the fact that it takes ownership. So this
> requires all callers to pass in scoped_ptrs.

Aha! LGTM :)

[awong, 2013-07-18 21:06:13]

lgtm

https://codereview.chromium.org/19731002/diff/1/chrome/browser/net/http_serve...
File chrome/browser/net/http_server_properties_manager.cc (right):

https://codereview.chromium.org/19731002/diff/1/chrome/browser/net/http_serve...
chrome/browser/net/http_server_properties_manager.cc:69:
HttpServerPropertiesManager::~HttpServerPropertiesManager() {
On 2013/07/18 20:34:29, akalin wrote:
> On 2013/07/18 18:13:57, awong wrote:
> > Reset the io_weak_ptr_factory_ first for WeakPtr<> hygiene?
> > 
> > As usual though, this concerns me because this class can be subclassed and
> since
> > we vend WeakPtrs from this factory in the public API, there's no way to
> > guarantee someone isn't going to use one when this object is partially
> > destructed...is this something you guys are deciding not to worry about?
> 
> Done.
> 
> I don't think implementations of HttpServerProperties are intended to be
> subclassed further. In particular, this implementation composes its underlying
> HttpServerPropertiesImpl instead of inheriting from it.
> 
> I'm not completely happy with adding a GetWeakPtr() function, but I don't
think
> stuff will get complex enough that we need to worry about weak ptrs and
partial
> destruction.

Famous Last Words. ;)

sgtm.

[akalin, 2013-07-18 21:19:02]

TBRing everyone else

[commit-bot: I haz the power, 2013-07-18 21:19:57]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/19731002/18001

[akalin, 2013-07-18 22:58:50]

Committed patchset #2 manually as r212466 (presubmit successful).