Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Consider reducing Mac usage #1

Closed
BanzaiMan opened this issue Jan 22, 2018 · 2 comments
Closed

Consider reducing Mac usage #1

BanzaiMan opened this issue Jan 22, 2018 · 2 comments

Comments

@BanzaiMan
Copy link

Currently, this repository is creating 5 Mac jobs for each build. With active development and cron jobs, it has more than 300 jobs queued up (but none of them is running; they are just waiting).

This is a huge burden on the system. Please consider canceling old ones and reducing the load.

Thanks.
@BanzaiMan
Copy link
Author

Sorry for the noise; we'll review the issue on our side.

@primiano
Copy link
Collaborator

Hey @BanzaiMan , yeah I noticed that there is some problem with the mac bots. It is pretty evident once you look to our CI frontend: https://perfetto-ci.appspot.com/

Here's a couple of things on my side:

  1. I think there is something odd with the mac builders. Our CI takes some minutes to build and <1 minute to run. This is a recent job I see in our queue and it took 5 mins to run. Can't tell why they are piling up.

  2. Yes, we kick 4 jobs for every CL sent. I would hope that your infrastructure isolates project, so even if we tick 1M jobs we don't end up stealing capacity from other projects.

  3. I'd also hope that you have some sort of TTL and give up on jobs > 1 day older (that would be definitely acceptable for us).

  4. As a stopgap solution, given that mac is best-effort support right now, I would be fine if we did exclude mac jobs from any branch other than master. If you give me an option to kick mac builds only for master I'll tick it (but only for mac, we really need jobs on all branches on the Linux builders)

Feel free to contact me, either here over email for more details.

P.S. FWIW we are paying Travis to get dedicated quota, but I suspect you realized that later on after filing the bug ;-)

primiano pushed a commit that referenced this issue Feb 8, 2018
@skyostil
[Patchset 5] Improve ftrace scheduling
2e169f7 
This patch implements the following ftrace scheduling model:



  main thread                           [drain] [unblock]
                                        /:              |
                            post .-----' :              |
                                /        :              v
  worker #0  [splice ...] [wakeup] [block ............] [splice]
                                         :
  worker #1  [splice ...]     [wakeup] [block ........] [splice]
                                         :
  worker #2  [splice ..........................................]
                                         :
                                         :
                                    drain period (100ms)



Change-Id: I9657a5d50cd936f190bc57f2c9778019cb7419ab
primiano pushed a commit that referenced this issue Feb 8, 2018
@skyostil
[Patchset 6] Improve ftrace scheduling
470b5da 
This patch implements the following ftrace scheduling algorithm:


  main thread                           [drain] [unblock]
                                        /:              |
                            post .-----' :              |
                                /        :              v
  worker #0  [splice ...] [wakeup] [block ............] [splice]
                                         :
  worker #1  [splice ...]     [wakeup] [block ........] [splice]
                                         :
  worker #2  [splice ..........................................]
                                         :
                                         :
                                    drain period (100ms)

In other words, the splice(2) system call is used to move data from
the raw kernel ftrace pipe into an intermediate pipe at a page
granularity. This call allows every per-cpu worker to sleep until there
is at least one page of data available.

When a worker wakes up, it will attempt to move as many pages as
possible to its staging pipe (up to 64K, depending on the
system's pipe buffer size) in a non-blocking way. After this, it
will notify the main thread that data is available. This notification
will block the calling worker until the main thread has drained the
data.

When at least one worker has woken up, we schedule a drain operation
on the main thread for the next drain period (every 100ms by default).
The drain operation parses ftrace data from the staging pipes of
every worker having pending data. After this, each waiting worker is
allowed to issue another call to splice(), restarting the cycle.

Change-Id: I9657a5d50cd936f190bc57f2c9778019cb7419ab
primiano pushed a commit that referenced this issue Feb 14, 2018
@skyostil
[Patchset 7] Improve ftrace scheduling
d669017 
This patch implements the following ftrace scheduling algorithm:


  main thread                           [drain] [unblock]
                                        /:              |
                            post .-----' :              |
                                /        :              v
  worker #0  [splice ...] [wakeup] [block ............] [splice]
                                         :
  worker #1  [splice ...]     [wakeup] [block ........] [splice]
                                         :
  worker #2  [splice ..........................................]
                                         :
                                         :
                                    drain period (100ms)

In other words, the splice(2) system call is used to move data from
the raw kernel ftrace pipe into an intermediate pipe at a page
granularity. This call allows every per-cpu worker to sleep until there
is at least one page of data available.

When a worker wakes up, it will attempt to move as many pages as
possible to its staging pipe (up to 64K, depending on the
system's pipe buffer size) in a non-blocking way. After this, it
will notify the main thread that data is available. This notification
will block the calling worker until the main thread has drained the
data.

When at least one worker has woken up, we schedule a drain operation
on the main thread for the next drain period (every 100ms by default).
The drain operation parses ftrace data from the staging pipes of
every worker having pending data. After this, each waiting worker is
allowed to issue another call to splice(), restarting the cycle.

Change-Id: I9657a5d50cd936f190bc57f2c9778019cb7419ab
primiano pushed a commit that referenced this issue Feb 15, 2018
@skyostil
Improve ftrace scheduling
247110b 
This patch implements the following ftrace scheduling algorithm:


  main thread                           [drain] [unblock]
                                        /:              |
                            post .-----' :              |
                                /        :              v
  worker #0  [splice ...] [wakeup] [block ............] [splice]
                                         :
  worker #1  [splice ...]     [wakeup] [block ........] [splice]
                                         :
  worker #2  [splice ..........................................]
                                         :
                                         :
                                    drain period (100ms)

In other words, the splice(2) system call is used to move data from
the raw kernel ftrace pipe into an intermediate pipe at a page
granularity. This call allows every per-cpu worker to sleep until there
is at least one page of data available.

When a worker wakes up, it will attempt to move as many pages as
possible to its staging pipe (up to 64K, depending on the
system's pipe buffer size) in a non-blocking way. After this, it
will notify the main thread that data is available. This notification
will block the calling worker until the main thread has drained the
data.

When at least one worker has woken up, we schedule a drain operation
on the main thread for the next drain period (every 100ms by default).
The drain operation parses ftrace data from the staging pipes of
every worker having pending data. After this, each waiting worker is
allowed to issue another call to splice(), restarting the cycle.

Change-Id: I9657a5d50cd936f190bc57f2c9778019cb7419ab
@jenics jenics mentioned this issue Oct 25, 2019
Open
primiano pushed a commit that referenced this issue Dec 3, 2019
@mspang
protozero: Fix use-of-uninitialized-value in MessageHandleBase
e09dcfb 
The diagnostic code in MessageHandleBase accesses an undefined value in
DCHECK builds:

==172==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x56024d8c3589 in protozero::MessageHandleBase::operator->() const ./../../third_party/perfetto/include/perfetto/protozero/message_handle.h:68:5
    #1 0x56025e928e5f in operator-> ./../../third_party/perfetto/include/perfetto/protozero/message_handle.h:116:47
    #2 0x56025e928e5f in tracing::(anonymous namespace)::ProtoWriter::AddDictEntry(char const*) ./../../services/tracing/public/cpp/perfetto/traced_value_proto_writer.cc:231:5
    #3 0x56025e921166 in tracing::(anonymous namespace)::ProtoWriter::SetInteger(char const*, int) ./../../services/tracing/public/cpp/perfetto/traced_value_proto_writer.cc:75:5
    #4 0x56025fcc90a6 in cc::benchmark_instrumentation::IssueDisplayRenderingStatsEvent() ./../../cc/benchmarks/benchmark_instrumentation.cc:24:16
    #5 0x56026026126c in viz::Display::DrawAndSwap() ./../../components/viz/service/display/display.cc:628:5
    #6 0x5602602c641e in viz::DisplayScheduler::DrawAndSwap() ./../../components/viz/service/display/display_scheduler.cc:215:38
    #7 0x5602602c4318 in viz::DisplayScheduler::AttemptDrawAndSwap() ./../../components/viz/service/display/display_scheduler.cc:488:14
    #8 0x5602602c2ec2 in viz::DisplayScheduler::OnBeginFrameDeadline() ./../../components/viz/service/display/display_scheduler.cc:504:19
    #9 0x56024b77fdb9 in base::OnceCallback<void ()>::Run() && ./../../base/callback.h:98:12
    #10 0x56025afac3d6 in Run ./../../base/callback.h:98:12
    #11 0x56025afac3d6 in base::TaskAnnotator::RunTask(char const*, base::PendingTask*) ./../../base/task/common/task_annotator.cc:142:33
    #12 0x56025b04d159 in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(base::sequence_manager::LazyNow*, bool*) ./../../base/task/sequence_manager/thread_controller_with_message_pump_impl.cc:365:23
    #13 0x56025b04c0f6 in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoSomeWork() ./../../base/task/sequence_manager/thread_controller_with_message_pump_impl.cc:219:7
    #14 0x56025ae37368 in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) ./../../base/message_loop/message_pump_default.cc:39:55
    #15 0x56025b050925 in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(bool, base::TimeDelta) ./../../base/task/sequence_manager/thread_controller_with_message_pump_impl.cc:463:12
    #16 0x56025af07594 in base::RunLoop::Run() ./../../base/run_loop.cc:156:14
    #17 0x56025b1171f0 in base::Thread::Run(base::RunLoop*) ./../../base/threading/thread.cc:305:13
    #18 0x56025b118599 in base::Thread::ThreadMain() ./../../base/threading/thread.cc:376:3
    #19 0x56025b2c2e2c in base::(anonymous namespace)::ThreadFunc(void*) ./../../base/threading/platform_thread_posix.cc:81:13
    #20 0x7f00bb5d9183 in pthread_create@@GLIBC_2.2.5 ??:0:0
    #21 0x7f00b5e7e03c in getspnam_r ??:0:0

  Uninitialized value was stored to memory at
    #0 0x56024d8afaf7 in protozero::Message::Reset(protozero::ScatteredStreamWriter*) ./../../third_party/perfetto/src/protozero/message.cc:64:14
    #1 0x56025e92052b in ProtoWriter ./../../services/tracing/public/cpp/perfetto/traced_value_proto_writer.cc:54:12
    #2 0x56025e92052b in make_unique<tracing::(anonymous namespace)::ProtoWriter, unsigned long &> ./../../buildtools/third_party/libc++/trunk/include/memory:3043:32
    #3 0x56025e92052b in tracing::(anonymous namespace)::CreateNestedValueProtoWriter(unsigned long) ./../../services/tracing/public/cpp/perfetto/traced_value_proto_writer.cc:256:10
    #4 0x56025b1ed987 in CreateWriter ./../../base/trace_event/traced_value.cc:436:12
    #5 0x56025b1ed987 in base::trace_event::TracedValue::TracedValue(unsigned long, bool) ./../../base/trace_event/traced_value.cc:459:26
    #6 0x56025fcc906d in cc::benchmark_instrumentation::IssueDisplayRenderingStatsEvent() ./../../cc/benchmarks/benchmark_instrumentation.cc:23:11
    #7 0x56026026126c in viz::Display::DrawAndSwap() ./../../components/viz/service/display/display.cc:628:5
    #8 0x5602602c641e in viz::DisplayScheduler::DrawAndSwap() ./../../components/viz/service/display/display_scheduler.cc:215:38
    #9 0x5602602c4318 in viz::DisplayScheduler::AttemptDrawAndSwap() ./../../components/viz/service/display/display_scheduler.cc:488:14
    #10 0x5602602c2ec2 in viz::DisplayScheduler::OnBeginFrameDeadline() ./../../components/viz/service/display/display_scheduler.cc:504:19
    #11 0x56024b77fdb9 in base::OnceCallback<void ()>::Run() && ./../../base/callback.h:98:12
    #12 0x56025afac3d6 in Run ./../../base/callback.h:98:12
    #13 0x56025afac3d6 in base::TaskAnnotator::RunTask(char const*, base::PendingTask*) ./../../base/task/common/task_annotator.cc:142:33
    #14 0x56025b04d159 in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(base::sequence_manager::LazyNow*, bool*) ./../../base/task/sequence_manager/thread_controller_with_message_pump_impl.cc:365:23
    #15 0x56025b04c0f6 in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoSomeWork() ./../../base/task/sequence_manager/thread_controller_with_message_pump_impl.cc:219:7
    #16 0x56025ae37368 in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) ./../../base/message_loop/message_pump_default.cc:39:55
    #17 0x56025b050925 in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(bool, base::TimeDelta) ./../../base/task/sequence_manager/thread_controller_with_message_pump_impl.cc:463:12
    #18 0x56025af07594 in base::RunLoop::Run() ./../../base/run_loop.cc:156:14
    #19 0x56025b1171f0 in base::Thread::Run(base::RunLoop*) ./../../base/threading/thread.cc:305:13
    #20 0x56025b118599 in base::Thread::ThreadMain() ./../../base/threading/thread.cc:376:3
    #21 0x56025b2c2e2c in base::(anonymous namespace)::ThreadFunc(void*) ./../../base/threading/platform_thread_posix.cc:81:13
    #22 0x7f00bb5d9183 in pthread_create@@GLIBC_2.2.5 ??:0:0

 Uninitialized value was created by a heap allocation
    #0 0x56024b74c9a9 in operator new(unsigned long) /b/swarming/w/ir/cache/builder/src/third_party/llvm/compiler-rt/lib/msan/msan_new_delete.cpp:45:35
    #1 0x56025e9203f7 in make_unique<tracing::(anonymous namespace)::ProtoWriter, unsigned long &> ./../../buildtools/third_party/libc++/trunk/include/memory:3043:28
    #2 0x56025e9203f7 in tracing::(anonymous namespace)::CreateNestedValueProtoWriter(unsigned long) ./../../services/tracing/public/cpp/perfetto/traced_value_proto_writer.cc:256:10
    #3 0x56025b1ed987 in CreateWriter ./../../base/trace_event/traced_value.cc:436:12
    #4 0x56025b1ed987 in base::trace_event::TracedValue::TracedValue(unsigned long, bool) ./../../base/trace_event/traced_value.cc:459:26
    #5 0x56025fcc906d in cc::benchmark_instrumentation::IssueDisplayRenderingStatsEvent() ./../../cc/benchmarks/benchmark_instrumentation.cc:23:11
    #6 0x56026026126c in viz::Display::DrawAndSwap() ./../../components/viz/service/display/display.cc:628:5
    #7 0x5602602c641e in viz::DisplayScheduler::DrawAndSwap() ./../../components/viz/service/display/display_scheduler.cc:215:38
    #8 0x5602602c4318 in viz::DisplayScheduler::AttemptDrawAndSwap() ./../../components/viz/service/display/display_scheduler.cc:488:14
    #9 0x5602602c2ec2 in viz::DisplayScheduler::OnBeginFrameDeadline() ./../../components/viz/service/display/display_scheduler.cc:504:19
    #10 0x56024b77fdb9 in base::OnceCallback<void ()>::Run() && ./../../base/callback.h:98:12
    #11 0x56025afac3d6 in Run ./../../base/callback.h:98:12
    #12 0x56025afac3d6 in base::TaskAnnotator::RunTask(char const*, base::PendingTask*) ./../../base/task/common/task_annotator.cc:142:33
    #13 0x56025b04d159 in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(base::sequence_manager::LazyNow*, bool*) ./../../base/task/sequence_manager/thread_controller_with_message_pump_impl.cc:365:23
    #14 0x56025b04c0f6 in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoSomeWork() ./../../base/task/sequence_manager/thread_controller_with_message_pump_impl.cc:219:7
    #15 0x56025ae37368 in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) ./../../base/message_loop/message_pump_default.cc:39:55
    #16 0x56025b050925 in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(bool, base::TimeDelta) ./../../base/task/sequence_manager/thread_controller_with_message_pump_impl.cc:463:12
    #17 0x56025af07594 in base::RunLoop::Run() ./../../base/run_loop.cc:156:14
    #18 0x56025b1171f0 in base::Thread::Run(base::RunLoop*) ./../../base/threading/thread.cc:305:13
    #19 0x56025b118599 in base::Thread::ThreadMain() ./../../base/threading/thread.cc:376:3
    #20 0x56025b2c2e2c in base::(anonymous namespace)::ThreadFunc(void*) ./../../base/threading/platform_thread_posix.cc:81:13
    #21 0x7f00bb5d9183 in pthread_create@@GLIBC_2.2.5 ??:0:0

Bug: chromium:1030032
Test: cast_shell_browsertests built with is_msan=true

Change-Id: I0f7fe0d0ec085f7a87028639e9a1ca70617fff3e
skyostil pushed a commit to skyostil/perfetto that referenced this issue Feb 11, 2023
@ddiproietto
api_integrationtest: Fix TSAN data race during shutdown
17e91c4 
TSAN reported the problem below on a CI run.

There's a possible sequence of events that can lead to this race (I'm
not sure it's the only one):
* The perfetto SDK thread calls the OnStop callback.
* The perfetto SDK thread is now inside WaitableTestEvent::Notify().
* The perfetto SDK thread sets notified_ to true and it unlocks the
  mutex, but does not call `cv_.notify_one()`.
* The main thread executes `WaitableTestEvent::Wait()`, which at this
  point can return.
* The main thread finishes executing the test and destroys the tracing
  sessions, which destroys the WaitableTestEvent and therefore `cv_`.
* The perfetto SDK thread resumes execution and tries to execute
  `cv_.notify_one()`, but that races with `cv_` destructor.

In order to prevent this race, we can just call `cv_.notify_one()` under
the lock. It might be less efficient, but it's correct.

This reverts part of https://r.android.com/1373304

https://ci.perfetto.dev/#!/logs/20221219192758--cls-2345694-4--linux-clang-x86_64-tsan

```
[00:07:40] [ RUN      ] PerfettoApiTest/PerfettoApiTest.TrackEventObserver_TwoDataSources/System
[00:07:40] [901.194] ing_service_impl.cc:980 Configured tracing session 1, #sources:1, duration:500 ms, #buffers:1, total buffer size:1024 KB, total sessions:1, uid:1337 session name: ""
[00:07:41] [901.697] ng_service_impl.cc:1921 FlushAndDisableTracing(1) done, success=1
[00:07:41] [901.698] ing_service_impl.cc:980 Configured tracing session 2, #sources:1, duration:500 ms, #buffers:1, total buffer size:1024 KB, total sessions:2, uid:1337 session name: ""
[00:07:41] [902.200] ng_service_impl.cc:1921 FlushAndDisableTracing(2) done, success=1
[00:07:42] ==================
[00:07:42] WARNING: ThreadSanitizer: data race (pid=7841)
[00:07:42]   Write of size 8 at 0x7b2000019c40 by main thread:
[00:07:42]     #0 pthread_cond_destroy ??:? (perfetto_integrationtests+0x315f8d) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#1 std::Cr::condition_variable::~condition_variable() ??:? (libc++.so+0xad729) (BuildId: bea413d45487d5c2)
[00:07:42]     catapult-project#2 (anonymous namespace)::PerfettoApiTest::TearDown() api_integrationtest.cc:? (perfetto_integrationtests+0x398609) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#3 testing::Test::Run() ??:? (perfetto_integrationtests+0x8de94f) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#4 testing::TestInfo::Run() ??:? (perfetto_integrationtests+0x8e0a2c) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#5 testing::TestSuite::Run() ??:? (perfetto_integrationtests+0x8e1b14) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#6 testing::internal::UnitTestImpl::RunAllTests() ??:? (perfetto_integrationtests+0x8f9e3f) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#7 testing::UnitTest::Run() ??:? (perfetto_integrationtests+0x8f8d36) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#8 main api_integrationtest_main.cc:? (perfetto_integrationtests+0x4d7aa4) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]
[00:07:42]   Previous read of size 8 at 0x7b2000019c40 by thread T3:
[00:07:42]     #0 pthread_cond_signal ??:? (perfetto_integrationtests+0x315c28) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#1 std::Cr::condition_variable::notify_one() ??:? (libc++.so+0xad479) (BuildId: bea413d45487d5c2)
[00:07:42]     catapult-project#2 void std::Cr::__function::__policy_invoker<void ()>::__call_impl<std::Cr::__function::__default_alloc_func<(anonymous namespace)::PerfettoApiTest::NewTrace(perfetto::protos::gen::TraceConfig const&, perfetto::BackendType, int)::{lambda()catapult-project#1}, void ()> >(std::Cr::__function::__policy_storage const*) api_integrationtest.cc:? (perfetto_integrationtests+0x39ba0a) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#3 perfetto::base::UnixTaskRunner::RunImmediateAndDelayedTask() unix_task_runner.cc:? (perfetto_integrationtests+0x594cfd) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#4 perfetto::base::UnixTaskRunner::Run() unix_task_runner.cc:? (perfetto_integrationtests+0x594133) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#5 perfetto::base::ThreadTaskRunner::RunTaskThread(std::Cr::function<void (perfetto::base::UnixTaskRunner*)>) thread_task_runner.cc:? (perfetto_integrationtests+0x592e4f) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#6 void* std::Cr::__thread_proxy[abi:v160000]<std::Cr::tuple<std::Cr::unique_ptr<std::Cr::__thread_struct, std::Cr::default_delete<std::Cr::__thread_struct> >, void (perfetto::base::ThreadTaskRunner::*)(std::Cr::function<void (perfetto::base::UnixTaskRunner*)>), perfetto::base::ThreadTaskRunner*, std::Cr::function<void (perfetto::base::UnixTaskRunner*)> > >(void*) thread_task_runner.cc:? (perfetto_integrationtests+0x59380b) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]
[00:07:42]   Location is heap block of size 120 at 0x7b2000019c00 allocated by main thread:
[00:07:42]     #0 operator new(unsigned long) ??:? (perfetto_integrationtests+0x3941a7) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#1 (anonymous namespace)::PerfettoApiTest::NewTrace(perfetto::protos::gen::TraceConfig const&, int) api_integrationtest.cc:? (perfetto_integrationtests+0x39b864) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#2 (anonymous namespace)::PerfettoApiTest::NewTraceWithCategories(std::Cr::vector<std::Cr::basic_string<char, std::Cr::char_traits<char>, std::Cr::allocator<char> >, std::Cr::allocator<std::Cr::basic_string<char, std::Cr::char_traits<char>, std::Cr::allocator<char> > > >, perfetto::protos::gen::TrackEventConfig, perfetto::protos::gen::TraceConfig) api_integrationtest.cc:? (perfetto_integrationtests+0x3a6385) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#3 (anonymous namespace)::PerfettoApiTest_TrackEventObserver_TwoDataSources_Test::TestBody() api_integrationtest.cc:? (perfetto_integrationtests+0x4a61d2) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#4 testing::Test::Run() ??:? (perfetto_integrationtests+0x8de8c3) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#5 testing::TestInfo::Run() ??:? (perfetto_integrationtests+0x8e0a2c) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#6 testing::TestSuite::Run() ??:? (perfetto_integrationtests+0x8e1b14) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#7 testing::internal::UnitTestImpl::RunAllTests() ??:? (perfetto_integrationtests+0x8f9e3f) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#8 testing::UnitTest::Run() ??:? (perfetto_integrationtests+0x8f8d36) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     #9 main api_integrationtest_main.cc:? (perfetto_integrationtests+0x4d7aa4) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]
[00:07:42]   Thread T3 'TracingMuxer' (tid=7845, running) created by main thread at:
[00:07:42]     #0 pthread_create ??:? (perfetto_integrationtests+0x3147ab) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#1 perfetto::base::ThreadTaskRunner::ThreadTaskRunner(std::Cr::basic_string<char, std::Cr::char_traits<char>, std::Cr::allocator<char> > const&) thread_task_runner.cc:? (perfetto_integrationtests+0x592b80) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#2 perfetto::(anonymous namespace)::PlatformPosix::CreateTaskRunner(perfetto::Platform::CreateTaskRunnerArgs const&) platform_posix.cc:? (perfetto_integrationtests+0x8c524a) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#3 perfetto::internal::TracingMuxerImpl::TracingMuxerImpl(perfetto::TracingInitArgs const&) tracing_muxer_impl.cc:? (perfetto_integrationtests+0x5a731c) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#4 perfetto::internal::TracingMuxerImpl::InitializeInstance(perfetto::TracingInitArgs const&) tracing_muxer_impl.cc:? (perfetto_integrationtests+0x5ad7fb) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#5 perfetto::Tracing::InitializeInternal(perfetto::TracingInitArgs const&) tracing.cc:? (perfetto_integrationtests+0x5c0f0d) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#6 (anonymous namespace)::ConcurrentSessionTest_ConcurrentBackends_Test::TestBody() api_integrationtest.cc:? (perfetto_integrationtests+0x4c3af4) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#7 testing::Test::Run() ??:? (perfetto_integrationtests+0x8de8c3) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     catapult-project#8 testing::TestInfo::Run() ??:? (perfetto_integrationtests+0x8e0a2c) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     #9 testing::TestSuite::Run() ??:? (perfetto_integrationtests+0x8e1b14) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     #10 testing::internal::UnitTestImpl::RunAllTests() ??:? (perfetto_integrationtests+0x8f9e3f) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     #11 testing::UnitTest::Run() ??:? (perfetto_integrationtests+0x8f8d36) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]     #12 main api_integrationtest_main.cc:? (perfetto_integrationtests+0x4d7aa4) (BuildId: 2d1df55c4bda2cdd)
[00:07:42]
[00:07:42] SUMMARY: ThreadSanitizer: data race ??:? in __interceptor_pthread_cond_destroy
[00:07:42] ==================
```

Change-Id: Ic822dba258b81a6c032633cf63763bd578739024
skyostil pushed a commit to skyostil/perfetto that referenced this issue Apr 27, 2023
@zezeozue
[stdlib] Add monitor contention helper functions
d6ee829 
Parsed all the monitor contention slices into two tables:
1. monitor_contention: Contains the raw parsed information with an
additional column |binder_reply_id| for correlating contention to
binder txns
2. monitor_contention_chain: Contains catapult-project#1 and an additional column
|parent_id| to represent the graph of contentions

In addition, exposed useful ANDROID_EXTRACT_MONITOR_CONTENTION_*
helper functions for extracting individual columns from a slice.

Test: tools/diff_test_trace_processor.py out/android/trace_processor_shell
Change-Id: I75f760d3a41887ee0bc90606c7cc064eff72b505
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@BanzaiMan @primiano