OOP HP crashes on start up on macOS |
||
Issue descriptionversion: 62.0.3201.0 I think that the previous version worked fine? Thread 24 ( * CRASHED * EXC_BAD_ACCESS / EXC_I386_GPFLT @ 0x107410317 ) 0 [Google Chrome Framework - string:1221] service_manager::Identity::operator<(service_manager::Identity const&) const 1 [Google Chrome Framework - __tree:2509] service_manager::ServiceManager::GetExistingInstance(service_manager::Identity const&) const 2 [Google Chrome Framework - service_manager.cc:229] service_manager::ServiceManager::Instance::CallOnBindInterface(std::__1::unique_ptr<service_manager::ConnectParams, std::__1::default_delete<service_manager::ConnectParams> >*) 3 [Google Chrome Framework - service_manager.cc:0] service_manager::ServiceManager::Connect(std::__1::unique_ptr<service_manager::ConnectParams, std::__1::default_delete<service_manager::ConnectParams> >) 4 [Google Chrome Framework - memory:2543] service_manager::ServiceManager::Instance::BindInterface(service_manager::Identity const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, mojo::ScopedHandleBase<mojo::MessagePipeHandle>, base::OnceCallback<void (service_manager::mojom::ConnectResult, service_manager::Identity const&)>) 5 [Google Chrome Framework - callback_forward.h:11] service_manager::mojom::ConnectorStubDispatch::AcceptWithResponder(service_manager::mojom::Connector*, mojo::Message*, std::__1::unique_ptr<mojo::MessageReceiverWithStatus, std::__1::default_delete<mojo::MessageReceiverWithStatus> >) 6 [Google Chrome Framework - connector.mojom.h:267] service_manager::mojom::ConnectorStub<mojo::RawPtrImplRefTraits<service_manager::mojom::Connector> >::AcceptWithResponder(mojo::Message*, std::__1::unique_ptr<mojo::MessageReceiverWithStatus, std::__1::default_delete<mojo::MessageReceiverWithStatus> >) 7 [Google Chrome Framework - interface_endpoint_client.cc:388] mojo::InterfaceEndpointClient::HandleValidatedMessage(mojo::Message*) 8 [Google Chrome Framework - multiplex_router.cc:0] mojo::internal::MultiplexRouter::ProcessIncomingMessage(mojo::internal::MultiplexRouter::MessageWrapper*, mojo::internal::MultiplexRouter::ClientCallBehavior, base::SequencedTaskRunner*) 9 [Google Chrome Framework - multiplex_router.cc:603] mojo::internal::MultiplexRouter::Accept(mojo::Message*) 10 [Google Chrome Framework - connector.cc:440] mojo::Connector::ReadSingleMessage(unsigned int*) 11 [Google Chrome Framework - connector.cc:469] mojo::Connector::ReadAllAvailableMessages() 12 [Google Chrome Framework - simple_watcher.h:194] mojo::SimpleWatcher::DiscardReadyState(base::RepeatingCallback<void (unsigned int)> const&, unsigned int, mojo::HandleSignalsState const&) 13 [Google Chrome Framework - weak_ptr.h:239] mojo::SimpleWatcher::OnHandleReady(int, unsigned int, mojo::HandleSignalsState const&) 14 [Google Chrome Framework - callback_forward.h:11] base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) 15 [Google Chrome Framework - vector:639] base::MessageLoop::RunTask(base::PendingTask*) 16 [Google Chrome Framework - message_loop.cc:524] base::MessageLoop::DoWork() 17 [Google Chrome Framework - message_pump_libevent.cc:220] base::MessagePumpLibevent::Run(base::MessagePump::Delegate*) 18 [Google Chrome Framework - run_loop.cc:124] base::RunLoop::Run() 19 [Google Chrome Framework - browser_thread_impl.cc:279] content::BrowserThreadImpl::IOThreadRun(base::RunLoop*) 20 [Google Chrome Framework - browser_thread_impl.cc:322] content::BrowserThreadImpl::Run(base::RunLoop*) 21 [Google Chrome Framework - lock.h:26] base::Thread::ThreadMain() 22 [Google Chrome Framework - platform_thread_posix.cc:77] base::(anonymous namespace)::ThreadFunc(void*) 23 [libsystem_pthread.dylib - 0x393b] _pthread_body 24 [libsystem_pthread.dylib - 0x3887] _pthread_body 25 [libsystem_pthread.dylib - 0x308d] thread_start 26 [Google Chrome Framework - platform_thread_posix.cc:52] base::(anonymous namespace)::ThreadFunc(void*)
,
Aug 31 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e932dca7c9960051685b87d85556d5b8f24ea1cc commit e932dca7c9960051685b87d85556d5b8f24ea1cc Author: Erik Chen <erikchen@chromium.org> Date: Thu Aug 31 23:03:57 2017 Increase the maximum buffer size of messages sent to MemlogSenderPipe. Writes on Posix greater than PIPE_BUF are not guaranteed to be atomic, but PIPE_BUF is potentially as low as 512, which isn't large enough to accomodate a message with 256 stack frames. Instead, use a large buffer size [artifically chosen to match that of Windows], and make the Send() method of the MemlogSenderPipe a critical section protected by a Lock. Bug: 761064 Change-Id: I7b4ef67d0f19bdf93d8239f5bd7bc9fddba6a4b4 Reviewed-on: https://chromium-review.googlesource.com/646661 Reviewed-by: Brett Wilson <brettw@chromium.org> Commit-Queue: Erik Chen <erikchen@chromium.org> Cr-Commit-Position: refs/heads/master@{#499062} [modify] https://crrev.com/e932dca7c9960051685b87d85556d5b8f24ea1cc/chrome/common/profiling/memlog_allocator_shim.cc [modify] https://crrev.com/e932dca7c9960051685b87d85556d5b8f24ea1cc/chrome/common/profiling/memlog_sender_pipe_posix.cc [modify] https://crrev.com/e932dca7c9960051685b87d85556d5b8f24ea1cc/chrome/common/profiling/memlog_sender_pipe_posix.h
,
Sep 1 2017
|
||
►
Sign in to add a comment |
||
Comment 1 by erikc...@chromium.org
, Aug 31 2017