1753539 - Trying to attach gdb to child process when media is playing leads to a rust panic

Status: ASSIGNED

(Core :: Audio/Video: cubeb, defect, P3)

Description

[Olli Pettay [:smaug][[e-mail]]]

Attachment: stack trace

I was debugging something else and the testcase required loading tiktok pages.
I used the following as an example
https://www.tiktok.com/@hpc_official/video/7011923672185212166?is_copy_url=1&is_from_webapp=v1
Soon after attaching gdb to the child process, rust panicked.

The issue happened many times, so I just stopped trying to use a debugger.
(Luckily some printfs were enough for me after all)
I couldn't reproduce the issue with youtube.

Comment 1

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Looks like this is audio (IPC) related. Chun-min, are you familiar with this? Could you help me triage?

Comment 2

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Clearing NI as it looks like :kinetik has this.

Comment 3

[Matthew Gregan [:kinetik]]

I haven't been able to repro this locally. I'm curious why the shmem region is reported as 1024 bytes when we expected it to be 393216 - it should've failed to initialize on the server side if we couldn't get the requested size. It's possible that mmap.len() on the client side returns a bogus value, but I'd like to know why (and why only under the debugger) if so.

Worth noting that this assert has been removed on the new development branch ("audioipc v2") since it's not possible to stat Android ashmem regions and as mentioned we trust the server to initialize the shmem with the correct size. It'd be simple to backport the assert removal, if that'd be useful, otherwise this issue may disappear in the next few weeks when v2 becomes the default.