INFO kernel: [  331.638182] traps: AudioThread[4253] trap int3 ip:57a0e4cb584e sp:7f65ade25fe0 error:0

looks suspicious to me, maybe an audio issue? Is this message also existing in the working version?

Though I removed working version and cannot test it right now, it actually looks suspicious.

I got backtrace by gdb:
https://paste.googleplex.com/5505414493896704

Hmm, the error seems to occur when doing mmap for DMA-buf.
https://cs.chromium.org/chromium/src/ui/gfx/linux/client_native_pixmap_dmabuf.cc?l=88&rcl=1415b5f0a7e468d91bdc8ce518a4df04f05b2e75

This looks similar to the problems we had before with betty, where minigbm virtio backend had incorrect plane size calculation for requested YUV format. 

I'd suggest checking if on amd64-generic in Chromium infra the same minigbm backend and/or pixel format is used. I'm not sure if there is any existing way to check that, so you might need to add some logs.

I made sure that virtio_gpu is also used on amd64-generic VM.

The crash is happening by the following way:
- Select resolution on webrtc demo page
- ResolveStreamBufferFormat calls CreateGpuMemoryBuffer with fixed size 128x128 [1]
- virtio_gpu_bo_create in minigbm is called
- mmap is called in client_native_pixmap_dmabuf.cc and it fails with "invalid arguments" error[2].
Here, |map_size| = 32768. This is calculated by adding plane's |offset| and |size|, which are both 16384.

I think this calculation of |map_size| is wrong for NV12, because the actual size in [3] was 24576, which is calculated in a special way in minigbm [4] that we worked before.
I guess we need to use the value obtained from minigbm as |map_size| here, but I'm not sure how we can do this.
Tomasz, how do you think?

In addition, I have no idea why vivid worked before.

[1] https://cs.chromium.org/chromium/src/media/capture/video/chromeos/camera_buffer_factory.cc?l=50&rcl=8f9ac80abbd502800b8a77101482a1285f7fc9a8
[2] https://cs.chromium.org/chromium/src/ui/gfx/linux/client_native_pixmap_dmabuf.cc?l=81&rcl=8f6326484a8c1ad74f61585eb0bfc7b1126ce2fa
[3] http://cs/chromeos_public/src/platform/minigbm/helpers.c?l=301&rcl=2b1d689b0c0a74db34fb69839d6c60b93e97141a
[4] http://cs/chromeos_public/src/platform/minigbm/helpers.c?l=273&rcl=2b1d689b0c0a74db34fb69839d6c60b93e97141a

I think the plane size should be populated by the buffer info returned by minigbm:

https://cs.chromium.org/chromium/src/ui/ozone/common/linux/gbm_wrapper.cc?type=cs&q=CreateBufferWithModifiers&g=0&l=143

Thanks for the information. Then, I'll check where the gap comes from.

By the way, why does Chrome has minigbm in /src/third_party/? When is it used?
It looks like my changes for ChromeOS's minigbm are not included there. Should we synchronize them manually?

Yes, you can roll the minigbm in src/third_party. The minigbm in src/third_party is mainly used to compile and test on non-ChromeOS environment. For Chrome on ChromeOS we build and link Chrome to the system library.

https://cs.chromium.org/chromium/src/third_party/minigbm/BUILD.gn?q=use_system_minigbm&sq=package:chromium&dr=C&l=14

Two important things to check here:

1) The method that fails (https://cs.chromium.org/chromium/src/ui/gfx/linux/client_native_pixmap_dmabuf.cc?l=81&rcl=8f6326484a8c1ad74f61585eb0bfc7b1126ce2fa) is private and only called from a public method called ImportFromDmabuf (https://cs.chromium.org/chromium/src/ui/gfx/linux/client_native_pixmap_dmabuf.cc?rcl=1d9c78149597bc68797982d9ac6294f9595fcd9f&l=63). That means that the plane offsets and sizes are actually populated from the import handle provided by whoever attempts to import such buffer. I'd check the call graph and see who does that import.

2) What's the format used to create the buffer that fails? Comment #7 mentions the resolution of 128x128, but doesn't mention the pixel format.

The format is gfx::BufferFormat::YUV_420_BIPLANAR. Some relevant code chunk:
https://cs.chromium.org/chromium/src/media/capture/video/chromeos/pixel_format_utils.cc?l=32-33&rcl=1d9c78149597bc68797982d9ac6294f9595fcd9f

I found that the cause of this crash was crrev.com/c/1158234, which was reverted by crrev.com/c/1232881. So, this crash no longer happens and I'll mark it fixed.

In short, the original CL was trying to calculate size of planes in gbm_wrapper instead of values that minigbm calculated, but it was incorrect.
https://chromium-review.googlesource.com/c/chromium/src/+/1158234/12/ui/ozone/common/linux/gbm_wrapper.cc#99
Please see Tomasz's comments for more detail.