jam@ - if I remember right you helped us a ton with the work to make the 32/64 bit interop safe across the IPC boundary, and I thought we were supposed to have mechanisms in place to avoid regressing this. Does that only apply to things actually passed via IPC, and not to things like this which are kept in shared memory? Is there any way for us to detect/prevent this kind of issue in general?

Jie kindly uploaded https://chromium-review.googlesource.com/#/c/chromium/src/+/752428/ to fix this structure, but I'm not sure that just reordering the fields is the best answer here; is there a way we can solve this more generally? It looks like we're already doing special things to mark shmem structures..

Dmitry: do you think check-ipc plugin can look for this?

If all such structs are specially marked (ALIGNAS(PARAMETERS_ALIGNMENT) looks like?) If so, I think we can detect alignment issues in check-ipc plugin.

But can't we just kill the padding with attribute(packed)? 

Conceivably adding attribute(packed) will affect performance in some cases (no idea if this is one of them, I'd have to ask one of the owners of the code in question). Not sure we'd want to do this as a blanket thing..

But we have just 2 choices here:

1. Either use attribute(packed), and deal with performance issues due to unaligned access.

2. Or rearrange fields, and have something (check-ipc plugin?) check their order to avoid regressions.

Hmm, but reordering wont work if struct doesn't have any 4-byte fields, i.e.

struct Bad {
  uin8_t code;
  int64_t timestamp;
};

Can't be fixed by reordering.

So maybe we should go with attribute(packed), but also arrange fields in descending (size, alignment) order?

PARAMETERS_ALIGNMENT is a local definition in the file where this particular structure appears, not a global thing. And MEDIA_SHMEM_EXPORT is specific to src/media and there don't appear to be equivalents anywhere else.

So.. maybe there isn't a global way to deal with this problem? I don't know what other parts of the codebase might put structs in shmem..

May we turn off the 32bit mode for IA specifically before a decent fix is found? It seems not a easy one to fix.

No, there's no easy way to disable using 32-bit renderers (the same setting controls the behaviour of chrome itself, and chrome can't currently run in 64-bit when launched from the monochrome APK due to the build configuration).

For now we can land the CL to fix this particular structure but we should see what we can think of as a generic solution; I've pinged the media/ OWNERS for your CL.

If most of shared memory usage is via SharedMemory, we can create specific method to cast its memory (memory->as<T>() instead of cast<T*>(memory->memory()), and have clang plugin check alignment for all types used by instantiations of that method.

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

commit c1ab361d6e08584b1e6d76ab5cefca0096ce80ed
Author: jchen10 <jie.a.chen@intel.com>
Date: Thu Dec 07 04:21:47 2017

Fix memory alignment for audio buffer parameters

x86 and x64 have different default alignment for 'long long' and
'double'. The browser and renderer processes of Android webview
run in 64-bit and 32-bit modes respectively. So we need to
deliberately arrange buffer fields to avoid misalignment.

BUG= 781095 

Change-Id: Icb6bade57d6d977468fe9c83a77f1e56d8875f90
Reviewed-on: https://chromium-review.googlesource.com/752428
Commit-Queue: Jie A Chen <jie.a.chen@intel.com>
Reviewed-by: Richard Coles <torne@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#522334}
[modify] https://crrev.com/c1ab361d6e08584b1e6d76ab5cefca0096ce80ed/media/base/audio_parameters.h

We don't really have any great ideas for preventing this class of problem in future, and use of shared memory in this way is fairly uncommon in the first place, so for now I'm just going to close this unless anyone comes up with a good plan.