Added more detailed result codes for CreateViewCommandBuffer.

Added more detailed result codes for CreateViewCommandBuffer.

Creation of a view command buffer can legitimately fail if the surface
has unexpectedly been deleted, for example if the window has been
rapidly opened and closed. This should not cause loss of the entire
GpuChannel for the associated renderer process.

Added new automated test for this issue. Also tested manually with
test case from bug report, and increased number_of_gpu_process_kills
in context_lost test to 30 and verified that previous fix for Issue
365904 continues to work.

BUG=381024
R=piman@chromium.org,danakj@chromium.org,jamesr@chromium.org

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

[Ken Russell (switch to Gerrit), 2014-07-11 23:02:01]

Antoine, Dana, James: please review. Thanks.

[piman, 2014-07-11 23:20:10]

lgtm

https://codereview.chromium.org/383303004/diff/1/content/browser/gpu/gpu_proc...
File content/browser/gpu/gpu_process_host.cc (right):

https://codereview.chromium.org/383303004/diff/1/content/browser/gpu/gpu_proc...
content/browser/gpu/gpu_process_host.cc:650: // and Send failing, if desired.
Really, we should assert and fix it upstream

https://codereview.chromium.org/383303004/diff/1/content/browser/gpu/gpu_proc...
content/browser/gpu/gpu_process_host.cc:759: callback.Run(succeeded ?
CREATE_CMDBUF_SUCCEEDED : CREATE_CMDBUF_FAILED);
ideally we'd pass a CreateCommandBufferResult back from the GPU process. Looking
at it currently the only reason this fails is if the client messed up its
routing id allocation (or is malicious), or it wrapeed around and we collided...
should we cause a CHANNEL_LOST in that case? We might be able to recover
slightly better.

https://codereview.chromium.org/383303004/diff/1/content/common/gpu/gpu_resul...
File content/common/gpu/gpu_result_codes.h (right):

https://codereview.chromium.org/383303004/diff/1/content/common/gpu/gpu_resul...
content/common/gpu/gpu_result_codes.h:11: CREATE_CMDBUF_SUCCEEDED,
nit: CMDBUF->COMMAND_BUFFER

[Ken Russell (switch to Gerrit), 2014-07-12 00:44:52]

jschuh/cevans/inferno: OWNERS review of gpu_messages.h please.

Managed to write an automated test for this issue.

https://codereview.chromium.org/383303004/diff/1/content/browser/gpu/gpu_proc...
File content/browser/gpu/gpu_process_host.cc (right):

https://codereview.chromium.org/383303004/diff/1/content/browser/gpu/gpu_proc...
content/browser/gpu/gpu_process_host.cc:759: callback.Run(succeeded ?
CREATE_CMDBUF_SUCCEEDED : CREATE_CMDBUF_FAILED);
On 2014/07/11 23:20:09, piman (slow to review) wrote:
> ideally we'd pass a CreateCommandBufferResult back from the GPU process.
Looking
> at it currently the only reason this fails is if the client messed up its
> routing id allocation (or is malicious), or it wrapeed around and we
collided...
> should we cause a CHANNEL_LOST in that case? We might be able to recover
> slightly better.

Thanks, that sounds cleaner. I've implemented this.

https://codereview.chromium.org/383303004/diff/1/content/common/gpu/gpu_resul...
File content/common/gpu/gpu_result_codes.h (right):

https://codereview.chromium.org/383303004/diff/1/content/common/gpu/gpu_resul...
content/common/gpu/gpu_result_codes.h:11: CREATE_CMDBUF_SUCCEEDED,
On 2014/07/11 23:20:10, piman (slow to review) wrote:
> nit: CMDBUF->COMMAND_BUFFER

Sure. Done.

[jschuh, 2014-07-14 13:37:10]

ipc security lgtm (notes: replaced bool with an integer error code).

[Ken Russell (switch to Gerrit), 2014-07-14 17:33:18]

The CQ bit was checked by kbr@chromium.org

[commit-bot: I haz the power, 2014-07-14 17:34:59]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/kbr@chromium.org/383303004/40001

[commit-bot: I haz the power, 2014-07-14 23:42:51]

Change committed as 283085