New issue
Advanced search Search tips

Issue 673414 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

base_unittests MemoryDumpManagerTest.PostTaskForSequencedTaskRunner failing

Project Member Reported by mbjorge@google.com, Dec 12 2016

Issue description

Running this on the v1 chromecast devices is failing with:

[ RUN      ] MemoryDumpManagerTest.PostTaskForSequencedTaskRunner
[616:616:1212/104243:2036053718:ERROR:memory_dump_manager.cc(524)] Disabling MemoryDumpProvider "TestDumpProvider". Failed to post task on the task runner provided.
[616:622:1212/104243:2036059629:FATAL:lock_impl_posix.cc(65)] Check failed: rv == 0 (22 vs. 0). Invalid argument
#0 0x0000b6c6ee08 base::debug::StackTrace::StackTrace()
#1 0x0000b6c8a35c logging::LogMessage::~LogMessage()
#2 0x0000b6cc5698 base::internal::LockImpl::Lock()
#3 0x0000b6d10bd4 base::SequencedWorkerPoolOwner::OnHasWork()
#4 0x0000b6cd92de base::SequencedWorkerPool::Inner::SignalHasWork()
#5 0x0000b6cd9d28 base::SequencedWorkerPool::Inner::PostTask()
#6 0x0000b6cda164 base::SequencedWorkerPool::PostSequencedWorkerTask()
#7 0x0000b6be5ace base::trace_event::TestSequencedTaskRunner::PostDelayedTask()
#8 0x0000b6cc9fa8 base::TaskRunner::PostTask()
#9 0x0000b6ce9f7e base::trace_event::MemoryDumpManager::SetupNextMemoryDump()
#10 0x0000b6cea39e base::trace_event::MemoryDumpManager::InvokeOnMemoryDump()
#11 0x0000b6cda9be base::SequencedWorkerPool::Inner::ThreadLoop()
#12 0x0000b6cdb0c4 base::SequencedWorkerPool::Worker::Run()
#13 0x0000b6cdb4fa base::SimpleThread::ThreadMain()
#14 0x0000b6cd6908 base::(anonymous namespace)::ThreadFunc()

[614:615:1212/104243:2036269566:ERROR:kill_posix.cc(84)] Unable to terminate process group 616: No such process
[1/1] MemoryDumpManagerTest.PostTaskForSequencedTaskRunner (CRASHED)
1 test crashed:
    MemoryDumpManagerTest.PostTaskForSequencedTaskRunner (../../base/trace_event/memory_dump_manager_unittest.cc:539)

Thought it might be related to https://bugs.chromium.org/p/chromium/issues/detail?id=658766


 

Comment 1 by mbjorge@google.com, Dec 12 2016

Link to test in question: https://cs.chromium.org/chromium/src/base/trace_event/memory_dump_manager_unittest.cc?q=PostTaskForSequencedTaskRunner&sq=package:chromium&l=570

It appears something is going wrong on the second RequestGlobalDumpAndWait due to task_runner1 being enabled.

Commenting out the second RequestGlobalDumpAndWait, or setting task_runner1->set_enabled(false) again in the second one both allow the test to succeed without crashing

Comment 2 by mbjorge@google.com, Dec 12 2016

Cc: ssid@chromium.org

Comment 3 by danakj@chromium.org, Dec 14 2016

Cc: robliao@chromium.org gab@chromium.org
Owner: fdoray@chromium.org
friendly ping here. Any useful tests I could do on device that might shed some light on the issue?

Comment 5 by gab@chromium.org, Feb 9 2017

Components: Internals>Cast
Owner: ----
Error 22 returned from pthread_mutex_lock is EINVAL:

[EINVAL]
The mutex was created with the protocol attribute having the value PTHREAD_PRIO_PROTECT and the calling thread's priority is higher than the mutex's current priority ceiling.

or

[EINVAL]
The value specified by mutex does not refer to an initialised mutex object.

according to http://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_mutex_lock.html


If changing the task runners has an impact on this bug I suspect it's because of the first one. Might have something to do with thread priorities and default lock policy on Chromecast?

We could also consider using PTHREAD_PRIO_INHERIT instead but robliao@ discovered it was broken on most POSIX impls... (broken on Linux and not implemented on Android...)

This bug is related to the Chromecast framework IMO.
Thanks for the feedback! I can experiment with setting PTHREAD_PRIO_INHERIT and  see if it makes a difference.

Comment 7 by sko...@chromium.org, Feb 16 2017

Status: Available (was: Untriaged)
Owner: mbjorge@chromium.org
Status: Assigned (was: Available)

Comment 10 by w...@chromium.org, Nov 21 2017

mbjorge: Did you verify whether PTHREAD_PRIO_INHERIT addresses this?
Owner: bcf@chromium.org
:( sorry, no, this one fell off my radar and I'm on a rotation with another team for the next several months, so likely won't have a chance to look at it.

bcf@ do you have any bandwidth to try out the suggestion in #5?
Owner: almasrymina@chromium.org

Sign in to add a comment