Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 682084

Summary: www-client/google-chrome with >=sys-libs/glibc-2.29 core dumps when trying to run flash
Product: Gentoo Linux Reporter: Harris Landgarten <harrisl>
Component: Current packagesAssignee: Chromium Project <chromium>
Status: CONFIRMED ---    
Severity: normal CC: atalanta.bergamo, che, johannes.hirte, kuba, pacho
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
URL: https://crbug.com/949312
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: backtrace
backtrace without ANSI colors
Ubuntu's patch for chromium

Description Harris Landgarten 2019-03-30 22:48:58 UTC
After allowing flash on a webpage the new google-chrome-beta shows "right click to run flash". The right click shows a run flash button but when it is clicked nothing runs and the system log shows a core dump.
Comment 1 Johannes Hirte 2019-03-31 08:46:28 UTC
I have the same behaviour with www-client/google-chrome-73.0.3683.86 and www-client/chromium-73.0.3683.86. First observed after the update of sys-libs/glibc to version 2.29-r1. Seems, it's related to this update.
Comment 2 Johannes Hirte 2019-03-31 09:12:20 UTC
Flash with Firefox/npapi still works.
Comment 3 Mike Gilbert gentoo-dev 2019-03-31 17:07:29 UTC
Created attachment 571404 [details]
backtrace

Core was generated by `/opt/google/chrome/chrome --type=ppapi --field-trial-handle=3570740548462328202'.
Program terminated with signal SIGSYS, Bad system call.
#0  clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:78
78      ../sysdeps/unix/sysv/linux/x86_64/clone.S: No such file or directory.
[Current thread is 1 (Thread 0x7f98909eba00 (LWP 1))]
Comment 4 Mike Gilbert gentoo-dev 2019-03-31 17:23:16 UTC
Created attachment 571406 [details]
backtrace without ANSI colors
Comment 5 Mike Gilbert gentoo-dev 2019-03-31 17:29:55 UTC
libpepflashplayer.so appears to call system("echo NOT SANDBOXED"). This calls clone(2), which is probably not allowed by the seccomp system call filter.

I suggest you report this to the Google Chrome team via the "Report an issue" dialog box in Google Chrome. You can find this in the menu, or by pressing Alt-Shift-I.
Comment 6 Mike Gilbert gentoo-dev 2019-03-31 17:37:42 UTC
This change in behavior was probably introduced here:

https://sourceware.org/git/?p=glibc.git;a=commit;h=5fb7fc96350575c9adb1316833e48ca11553be49

This changed system(3) from calling fork(2) to clone(2).
Comment 7 Mike Gilbert gentoo-dev 2019-03-31 17:52:23 UTC
Technically, they both call clone(2), but with different flags.

Pre 2.29: clone(child_stack=NULL, flags=CLONE_PARENT_SETTID|SIGCHLD, parent_tidptr=0x11f950fd0)

Post 2.29: clone(child_stack=0x7f6bb82c2ff0, flags=CLONE_VM|CLONE_VFORK|SIGCHLD)
Comment 8 Mike Gilbert gentoo-dev 2019-03-31 18:30:40 UTC
As a workaround, you can start chrome with the --disable-seccomp-filter-sandbox command line option.
Comment 9 Mike Gilbert gentoo-dev 2019-04-03 21:17:48 UTC
Reported upstream.
Comment 10 Harris Landgarten 2019-05-29 02:04:16 UTC
Issue is fixed on latest google-chrome-unstable Version 76.0.3800.0 (Official Build) dev (64-bit)

It is still an issue on google-chrome-beta
Comment 11 Andreas Berg 2019-06-01 08:14:52 UTC
Created attachment 578306 [details, diff]
Ubuntu's patch for chromium

Successfully tested with chromium-73.0.3683.86
Comment 12 Pacho Ramos gentoo-dev 2019-06-01 16:58:08 UTC
(In reply to Mike Gilbert from comment #8)
> As a workaround, you can start chrome with the
> --disable-seccomp-filter-sandbox command line option.

glibc-2.29 went to stable (bug #685818) ... I am unsure about passing that option by default as a workaround for the case upstream doesn't fix it for google-chrome-stable :/