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 packages | Assignee: | Chromium Project <chromium> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | atalanta.bergamo, che, johannes.hirte, kuba.iluvatar, 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
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. Flash with Firefox/npapi still works. 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))]
Created attachment 571406 [details]
backtrace without ANSI colors
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. 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). 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) As a workaround, you can start chrome with the --disable-seccomp-filter-sandbox command line option. Reported upstream. 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 Created attachment 578306 [details, diff]
Ubuntu's patch for chromium
Successfully tested with chromium-73.0.3683.86
(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 :/ Was fixed in chrome in May 2019. Let's close the bug. |