Headless quietly stops when adding WebRTC video

[cha...@tokbox.com]

Hi all-

I need help tracking down the cause of some misbehavior on headless Chrome. I've got a broadcast application that works great inside headless, right up until a second video stream is added to the session. Everything seems to just freeze up without much sign as to why. With verbose logging enabled, all I see is one lousy warning from the audio bus:

[0802/185550.051655:WARNING:audio_sync_reader.cc(191)] AudioSyncReader::Read timed out, audio glitch count=1

[0802/185550.051707:WARNING:audio_sync_reader.cc(174)] ASR: No room in socket buffer.: Broken pipe

Prior to this, there's quite a lot of log spew from WebRTC, but nothing unusual (can send logs privately if needed). After these messages fire, there is nothing in logs whatsoever, as if the page completely stopped. The process seems to have frozen completely. I haven't tried sending commands via devtools protocol, but when I run this with a screencast and event hooks for console messages, nothing comes back from the process at all.

Setup details:

* Running in Docker

* ALSA + Pulseaudio on loopback

* Linux 16.04.2

* Repro with google-chrome-stable (M60), and -unstable (M61)

Call flags:

google-chrome-unstable --no-sandbox --no-zygote --hide-scrollbars --user-agent="Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.78 Safari/537.36" --enable-logging --v=9999999 --window-size=1280,720 --headless --disable-gpu --enable-tracing --remote-debugging-port=9222 https://asdf1234.ngrok.io/archive_composer/-KqYaFhAwwTiRBAYKJmGdU

Oddly, I can take other demo apps and get those same two WebRTC streams to work fine inside headless, so I'm more suspicious of something happening on the render than problems at the network layer. Alas, I'm stumped.

Would a crash get logged somewhere differently? Where should I look next? Any advice on digging out possible causes or just more data for this panic would be most appreciated.

Thanks!

[cha...@tokbox.com]

For anyone coming back to this: 

This is a crash. I'm still not sure where the crash data is going in this case (would love a hint from the team on this!). 

Anyway, it seems the issue comes down to tmpfs memory consumption with Docker. Bump up --shm-size to something greater than 64M as Docker. 

I used 512M and it seems to have resolved the issue.

Supplemental reading: https://bugs.chromium.org/p/chromium/issues/detail?id=522853

Thanks again all!

[Sami Kyostila]

For future reference, you can use --crash-dumps-dir=/tmp --enable-crash-reporter to get a crash dump out of headless and attach it to a bug.

- Sami

--
You received this message because you are subscribed to the Google Groups "headless-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to headless-dev...@chromium.org.
To post to this group, send email to headle...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/headless-dev/3b32b4ce-a3bc-467e-9806-f13391b9a157%40chromium.org.