New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 848751 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Aug 30
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Bug

Blocking:
issue 843511



Sign in to add a comment

Various Window*Tests in services_unittests on ToTLinuxUBSanVptr

Project Member Reported by thakis@chromium.org, Jun 1 2018

Issue description

https://ci.chromium.org/buildbot/chromium.clang/ToTLinuxUBSanVptr/2933

WindowTreeClientTest.TransientWindowTracksTransientParentLifetime
WindowTreeClientTest.EmbedWithSameWindowId2
WindowTreeClientTest.EmbedFromOtherClient
WindowTreeClientTest.AddUnknownWindowKnownParent
WindowServerTest.Embed
WindowServerTest.Reorder
WindowTreeClientTest.AddWindowWithNoChange
WindowTreeClientTest.SetOpacityNotifications
WindowServerTest.EstablishConnectionViaFactory
WindowTreeClientTest.TwoClientsGetDifferentClientIds


Theses tests have been failing consistently since I added service_unittests to the bots, but they were green once in https://ci.chromium.org/buildbot/chromium.clang/ToTLinuxUBSanVptr/2932 (and then red again).


The stacks on the failed shard's stdout are a bit longer, here's one:

[ RUN      ] WindowServerTest.Embed
Received signal 11 SEGV_MAPERR 7f3e57fe8be0
#0 0x000000e7ce6d base::debug::StackTrace::StackTrace()
#1 0x000000e7c7f3 base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x7f3e5fafa330 <unknown>
#3 0x000000626a63 __sanitizer_cov_trace_pc_guard
#4 0x000001728b6f FcStrBufDestroy
#5 0x0000017326cf FcPStackPop
#6 0x00000173114f FcEndElement
#7 0x00000176b76f xmlParseEndTag1
#8 0x0000017751a2 ../../services/ui/ws/window_server_test_base.cc:109: Failure
Value of: DoRunLoopWithTimeout()
  Actual: false
Expected: true
Stack trace:
#0 0x000002eaf53d testing::internal::UnitTestImpl::CurrentOsStackTraceExceptTop()
#1 0x000002eae335 testing::internal::AssertHelper::operator=()
#2 0x00000c35d835 ui::WindowServerTestBase::SetUp()

[  FAILED  ] WindowServerTest.Embed (10032 ms)

They're all in libxml, and then at __sanitizer_cov_trace_pc_guard.

I'm not sure I believe the stacks though, window_server_test_base.cc doesn't obviously call xml stuff. +sky for window_server_test_base and +mmoroz for coverage.
 
Oh, that stack is irrelevant I think; this is the important bit:

Value of: DoRunLoopWithTimeout()
  Actual: false
Expected: true
Stack trace:
#0 0x000002eaf53d testing::internal::UnitTestImpl::CurrentOsStackTraceExceptTop()
#1 0x000002eae335 testing::internal::AssertHelper::operator=()
#2 0x00000c35d835 ui::WindowServerTestBase::SetUp()


So I guess this

  // Connecting as the WindowManager results in OnWmNewDisplay() being called
  // with the display (and root). Wait for it to be called so we have display
  // and root window information (otherwise we can't really do anything).
  ASSERT_TRUE(DoRunLoopWithTimeout());

times out. sky, does this test need gpu hardware or something?

Comment 2 by sky@chromium.org, Jun 1 2018

Is this the same as 848278?
protip: if you prefix bug numbers with "bug" or "issue", monorail will linkify them, e.g. " issue 848278 " (mostly saying that so I can click on it)
Maybe it's related -- the green build had the revert https://chromium-review.googlesource.com/c/chromium/src/+/1081972 . But the next build was red again.

Comment 5 by sky@chromium.org, Jun 1 2018

Cc: jbudorick@chromium.org
Thanks for the protip (I didn't know it).

+jbudorick@chromium.org as he figured out 848278 and might have an idea if this is related.

Comment 6 by r...@chromium.org, Jun 5 2018

Do you think the timeout might be because some chrome child process crashed on startup? It looks like some subprocess might be generating the SEGV_MAPERR stack trace and them the DoRunLoopWithTimeout fails because it never hears back from the child process.
It sounds very similar to   issue 848278  to me, so I was hoping mmoroz could say what he makes of this.

Comment 8 by r...@chromium.org, Jun 6 2018

I think they are related, but nobody ever dug in to find the root cause of  issue 848278 . Our ubsan bot is configured with `sanitizer_coverage_flags = "trace-pc-guard"` in gn args, so it is still affected by the same issue, and wasn't affected by the revert mentioned in c#4.

I think it's probably on us to figure out what's gone wrong with sanitizer coverage in FcStrBufDestroy.
Cc: kcc@chromium.org
+kcc for any comments on stack in c#0 with __sanitizer_cov_trace_pc_guard
Can't say much on  issue 848278 , but indeed looks like sancov + sanitizers make some large test suites unstable.
Cc: -jbudorick@chromium.org
Owner: jbudorick@chromium.org
Status: Fixed (was: Untriaged)
This doesn't seem to be an issue anymore. Marking as Fixed and assigning to John who did the revert. We aren't going to re-land the change that caused the regression.

Sign in to add a comment