SEGV_MAPERR with --headless --repl
Reported by
kw.schi...@gmail.com,
Mar 2 2018
|
||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36 Steps to reproduce the problem: 1. Execute: chromium --headless --repl http://www.google.de 2. Type "quit" in the console and press enter What is the expected behavior? Should quit the browser without a SEGV_MAPERR error. What went wrong? The process crashes with a SEGV_MAPPER error. The www.google.de domain is the only domain that I found causing this particular crash. Other domains behave as desired. Furthermore, executing any other command before calling "quit", e.g. location.href and afterwards quit, does not yield a crash. Crashed report ID: no How much crashed? Whole browser Is it a problem with a plugin? No Did this work before? N/A Chrome version: 64.0.3282.186 Channel: stable OS Version: Flash Version: I have tested this also on a Mac, a friends Linux computer and on a custom build version. In the attachments there are the outputs of the crash. For the custom build chromium there is also a stack trace available.
,
Mar 6 2018
Thanks for the report. I'm seeing that crash as well as this one in debug mode which may be related: [0306/153834.667032:FATAL:lock_impl_posix.cc(76)] Check failed: rv == 0 (22 vs. 0). Invalid argument #0 0x7f3f7250d6ad base::debug::StackTrace::StackTrace() #1 0x7f3f7250bb9c base::debug::StackTrace::StackTrace() #2 0x7f3f72593bca logging::LogMessage::~LogMessage() #3 0x7f3f726d4983 base::internal::LockImpl::Lock() #4 0x7f3f724b79b3 base::Lock::Acquire() #5 0x7f3f724b76d3 base::AutoLock::AutoLock() #6 0x7f3f726793a6 base::SequenceCheckerImpl::CalledOnValidSequence() #7 0x7f3f726cf463 base::SupportsUserData::GetUserData() #8 0x7f3f6c3fe58c content::BrowserContext::GetServiceManagerConnectionFor() #9 0x7f3f6ce2dc49 content::RenderProcessHostImpl::Cleanup() #10 0x7f3f6ce262cc content::RenderProcessHostImpl::DecrementKeepAliveRefCount() #11 0x7f3f6c80242d content::KeepAliveHandleFactory::Context::Detach() #12 0x7f3f6c8061c9 content::KeepAliveHandleFactory::Context::~Context() #13 0x7f3f6c806197 base::RefCounted<>::DeleteInternal<>() #14 0x7f3f6c806165 base::DefaultRefCountedTraits<>::Destruct() #15 0x7f3f6c806148 base::RefCounted<>::Release() #16 0x7f3f6c806105 scoped_refptr<>::Release() #17 0x7f3f6c8020ca scoped_refptr<>::~scoped_refptr() #18 0x7f3f6c806641 content::KeepAliveHandleFactory::KeepAliveHandleImpl::~KeepAliveHandleImpl() #19 0x7f3f6c806679 content::KeepAliveHandleFactory::KeepAliveHandleImpl::~KeepAliveHandleImpl() #20 0x7f3f6c8042e0 content::mojom::KeepAliveHandleStub<>::~KeepAliveHandleStub() #21 0x7f3f6c8060cf mojo::internal::BindingState<>::~BindingState() #22 0x7f3f6c806095 mojo::Binding<>::~Binding() #23 0x7f3f6c806075 mojo::BindingSetBase<>::Entry::~Entry() #24 0x7f3f6c80523a mojo::BindingSetBase<>::OnConnectionError() #25 0x7f3f6c803c4b mojo::BindingSetBase<>::Entry::OnConnectionError() ... #85 0x00005555586ec6d5 in headless::HeadlessShellMain(int, char const**) (argc=4, argv=0x7fffffffda48) at ../../headless/app/headless_shell.cc:830 #86 0x00005555586ed120 in headless::HeadlessShellMain(content::ContentMainParams const&) (params=...) at ../../headless/app/headless_shell.cc:839 #87 0x0000555556cc7222 in ChromeMain(int, char const**) (argc=4, argv=0x7fffffffda48) at ../../chrome/app/chrome_main.cc:97 #88 0x0000555556cc7152 in main(int, char const**) (argc=4, argv=0x7fffffffda48) at ../../chrome/app/chrome_exe_main_aura.cc:17 I think the problem is we're somehow calling content::BrowserContext::GetServiceManagerConnectionFor on two different sequences.
,
Mar 6 2018
If I'm not mistaken, return value 22 is EINVAL, invalid argument. Sounds like possibly some sort of deconstruction race?
,
Mar 27 2018
Exactly, I've noticed that return value 22 tends to associate with use-after-free of Locks (I should update the check to make that clearer).
,
May 7 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3b3e255ba6659e5caf0197a2cf7b02ab50470f8e commit 3b3e255ba6659e5caf0197a2cf7b02ab50470f8e Author: Gabriel Charette <gab@chromium.org> Date: Mon May 07 22:56:51 2018 [Logging] Hint of use-after-free indicating error in POSIX's LockImpl. Error 22 (EINVAL) is often associated with use-after-frees. I've seen multiple developers independently spending cycles figuring this out. Add a hint for everyone once and for all in POSIX's LockImpl Issues where this may be useful: https://bugs.chromium.org/p/chromium/issues/list?q=%22Check+failed%3A+rv+%3D%3D+0+(22+vs.+0)%22 Sadly I couldn't find a way to test this. I tried to write a death test on a manual use-after-free but the error is unreliable. R=dcheng@chromium.org Bug: 818163 Change-Id: I2f9a3aeadebd8bd7b32e2a28d1ba4b801efed9ff Reviewed-on: https://chromium-review.googlesource.com/1040586 Reviewed-by: Daniel Cheng <dcheng@chromium.org> Commit-Queue: Gabriel Charette <gab@chromium.org> Cr-Commit-Position: refs/heads/master@{#556593} [modify] https://crrev.com/3b3e255ba6659e5caf0197a2cf7b02ab50470f8e/base/synchronization/lock_impl_posix.cc |
||
►
Sign in to add a comment |
||
Comment 1 by dtapu...@chromium.org
, Mar 5 2018