Docker + Chromium = SIGBUS

Aug 20, 2015

Tales of a bughunt

All began with reading @jfrazelle stuffs about dockerizing desktop apps. Some programs are not so good citizens, i.e. Okular leaves a KDE daemon running. Another serious contender is my browser, Chromium, which after the Google voice blob thing seemed appropriate to contain. Something that is more private than private browsing and cannot use my webcam/sound card would be really nice…

After learning Docker X sharing (simple bind mount), it should be easy to create or use someone else’s docker. Run it like

docker run --rm -it -e DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix:ro chromium_gui

and check some website: Aw, Snap!. From previous experience, it may be SIGSEGV Let’s check as usual: with gdb and strace:

#strace -ff -o log chromium --no-sandbox --user-data-dir=/tmp
log.143:--- SIGBUS {si_signo=SIGBUS, si_code=BUS_ADRERR, si_addr=0x7f3355a2b000} ---

SIGBUS on x86? gdb backtrace seems perfectly legal. Google was not really helpful on this. And this is the same even for ssh X forward. To check that this is really a Docker issue, I went insane:

mount --bind / /mnt/root/
mount --bind /sys/ /mnt/root/sys/
mount --bind /proc/ /mnt/root/proc/
mount --bind /dev/ /mnt/root/dev/
chroot /mnt/root/
chromium --no-sandbox --user-data-dir=/tmp

Of course, it worked. This bind mounts in Docker? Works too; turns out, only /dev is needed (on Debian jessie). Fortunately Debian sid (the other version I use) differs in that /dev/shm is a symlink to /run/shm. Mounting /dev worked only jessie; on sid I got something like:

Creating shared memory in /dev/shm/.org.chromium.Chromium.sSLYBL failed: Permission denied
Unable to access(W_OK|X_OK) /dev/shm: Permission denied
This is frequently caused by incorrect permissions on /dev/shm. Try 'sudo chmod 1777 /dev/shm' to fix.

This leads to this Docker issue and one possible workaround for the SIGBUS:

-v /dev/shm:/dev/shm -v /run/shm:/run/shm

Reduced steps to reproduce

What now? Is it that 64M /dev/shm is not enough for chromium? What if mount -o remount,size=64M /dev/shm? Aw, snap! Unfortunately watching the output of df came to my mind only this time. Chromium uses /dev/shm, but it does not really need shared memory; mount --bind /tmp/ /dev/shm/ works perfectly too. Getting this crash is not that far fetched; I managed get Aw, snap! on a machine with 2G RAM by leaving the same amount of tabs I usually do on my >8G machines.

Lessons learned

Google and Stack Overflow can be horribly wrong
SIGBUS-ing on tmpfs full is an awful error message
Watching the health of the system/docker container would have saved tons of time