Cause of the failure is that GpuChannelMsg_CreateCommandBuffer passes a gpu::SurfaceHandle - on Android & Mac that is a 32-bit Id generated by GpuSurfaceManager, X11 & Ozone it's the raw AcceleratedWidget identifier from the platform, which for X11 is an unsigned long.  Windows doesn't run this check.

On Ozone, though, the AcceleratedWidget is an intptr_t, so that trips this check.

It's fine to change this to int64_t.

Re #3: Does it actually need to be int64_t, or would int32_t make more sense, if all we're sending are surface-manager allocated Ids, in effect?

It's not necessarily surface manager allocated - as you said on X it's the X window id and therefore allocated by X. We have an ozone-on-X build these days.

int64_t is obviously wide enough on all platforms. int32_t probably is, but it's harder to prove. I do believe X counts from zero.

X window IDs are fixed at 32 bits. It's a network protocol :-)

They are fixed at 32-bits (CARD32) on-the-wire, but Xlib APIs map CARD32 on
to unsigned long, so we may still end up with some complaints from the
compiler about losing precision that we're not using. ;-(

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/af126a587f99d80a7a42bcfc4b76cffb3e78d974

commit af126a587f99d80a7a42bcfc4b76cffb3e78d974
Author: wez <wez@chromium.org>
Date: Wed Apr 27 22:33:43 2016

Redefine Ozone AcceleratedWidget as int32_t.

Ozone's AcceleratedWidget was defined as intptr_t, and then used "raw"
as gfx::SurfaceHandle in IPCs, triggering build-time IPC sanity-check
failures.

Defining it as int32_t passes the sanity-check and helps ensure that no
new code tries to put actual pointers in there by mistake.

BUG= 607014 

Review-Url: https://codereview.chromium.org/1925483003
Cr-Commit-Position: refs/heads/master@{#390219}

[modify] https://crrev.com/af126a587f99d80a7a42bcfc4b76cffb3e78d974/ui/gfx/native_widget_types.h