Ensure that the refcount on InternalGetCommandRequest stays non-zero through a PostTask

Ensure that the refcount on InternalGetCommandRequest stays non-zero through a PostTask

The problem was that BaseSessionService::ScheduleGetLastSessionCommands() was posting a task with a InternalGetCommandsRequest* request parameter by calling NewRunnableMethod(.., &SessionBackend::ReadLastSessionCommands, request).  SessnionBackend::ReadLastSessionCommands takes one parameter of type scoped_refptr<InternalGetCommandsRequest>.  However, NewRunnableMethod was matching the template because an InternalGetCommandsRequest* is implicitly convertable to a scoped_refptr<InternalGetCommandsRequest> but it was not actually creating the scoped_refptr<> (and thus bumping the refcount) until the task was dispatched.  By this time the refcount on the InternalGetCommandsRequest had already dropped to zero, leading to memory corruption.

This fixes the problem by passing a scoped_refptr<...> in to NewRunnableMethod() to ensure that it is copied and that the refcount stays up.

TEST=covered by TabRestoreUITest.RestoreIntoSameWindow - caused very intermittend failures locally
BUG=none

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=32240

[jamesr, 2009-11-17 23:53:43]

The failure reproduces much more reliably if the PostTask() is changed to a
PostDelayedTask() with some decent delay.

This failure mode is pretty alarming - it seems that any code that uses
Post*Task() to a function that takes a scoped_refptr<> parameter is likely to
fail in this way.  I'll try doing a build without the implicit T* to
scoped_refptr<T> and see how many template matches fail in Post*Task() to see
how common it is.

[jam, 2009-11-18 00:10:13]

great catch.  that's crazy though.  can we prevent this from happening again,
either through compile/runtime checks?