New issue
Advanced search Search tips

Issue 862466 link

Starred by 2 users

Issue metadata

Status: Closed
Owner: ----
Closed: Oct 12
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: ----



Sign in to add a comment

browser_tests failing on chromium.mac/Mac10.12 Tests and Mac10.11 Tests

Project Member Reported by sheriff-...@appspot.gserviceaccount.com, Jul 11

Issue description

Filed by sheriff-o-matic@appspot.gserviceaccount.com on behalf of dpranke@google.com

browser_tests failing on chromium.mac/Mac10.12 Tests

Builders failed on: 
- Mac10.12 Tests: 
  https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Mac10.12%20Tests


 
Cc: -dpranke@google.com rsesek@chromium.org dpranke@chromium.org mark@chromium.org
Components: Internals>CrashReporting
Labels: -Pri-2 Pri-1
Summary: browser_tests failing on chromium.mac/Mac10.12 Tests and Mac10.11 Tests (was: browser_tests failing on chromium.mac/Mac10.12 Tests)
Also Mac10.11 Tests
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Mac10.11%20Tests

The tests seem fairly varied, as if something gets wedged on the machine and suddenly ever test fails in crashpad:

https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Mac10.12%20Tests/14342
https://chromium-swarm.appspot.com/task?id=3e9f285c6b7d6e10&refresh=10&show_raw=1
Cc: aboxhall@chromium.org
I don't see anything obvious in the blamelist. I'm going to speculatively revert https://crrev.com/c/1128630 which is the only thing particularly close to plausible I see in that list; failing that we'll likely need to bisect the failures and see what's going on.
Cc: alph@chromium.org
Hmm, looks like a sampling-heap-profiler layout test started failing on the WebKit Linux MSAN bot in the same revision window, and has been failing fairly consistently since:

https://ci.chromium.org/buildbot/chromium.webkit/WebKit%20Linux%20Trusty%20MSAN/8814
https://ci.chromium.org/buildbot/chromium.webkit/WebKit%20Linux%20Trusty%20MSAN/8816
https://ci.chromium.org/buildbot/chromium.webkit/WebKit%20Linux%20Trusty%20MSAN/8817

This makes me slightly more optimistic that this CL is at fault.

Some more info I collected while sheriffing yesterday:

Since at least https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Mac10.11%20Tests/27804, Mac 10.11 browsertests have often had the below DCHECK go off. I looked at the commits in that run and the couple runs before but didn't see anything obvious, and also looked through recent rolls of crashpad but again didn't see anything suspicious in the commits being brought in. Mark, any thoughts?

[ RUN      ] ChromeContentBrowserClientBrowserTest.SitePerProcessNavigation
[0702/125406.779347:ERROR:mach_extensions.cc(68)] bootstrap_check_in org.chromium.crashpad.child_port_handshake.7358.115704.YLVEVTGTFTEBUIPO: unknown error code (141)
[0702/125406.779472:FATAL:child_port_handshake.cc(111)] Check failed: server_port.is_valid().
0   crashpad_handler                    0x000000010aa3c6bc base::debug::StackTrace::StackTrace(unsigned long) + 28
1   crashpad_handler                    0x000000010aa299c1 logging::LogMessage::~LogMessage() + 225
2   crashpad_handler                    0x000000010aa46394 crashpad::ChildPortHandshake::RunServerForFD(base::ScopedGeneric<int, base::internal::ScopedFDCloseTraits>, crashpad::ChildPortHandshake::PortRightType) + 516
3   crashpad_handler                    0x000000010aa18876 crashpad::HandlerMain(int, char**, std::__1::vector<std::__1::unique_ptr<crashpad::UserStreamDataSource, std::__1::default_delete<crashpad::UserStreamDataSource> >, std::__1::allocator<std::__1::unique_ptr<crashpad::UserStreamDataSource, std::__1::default_delete<crashpad::UserStreamDataSource> > > > const*) + 4790
4   libdyld.dylib                       0x00007fff989965ad start + 1
5   ???                                 0x0000000000000008 0x0 + 8
[0702/125406.780147:ERROR:file_io.cc(89)] ReadExactly: expected 4, observed 0
[0702/125406.780941:ERROR:mach_extensions.cc(68)] bootstrap_check_in org.chromium.crashpad.child_port_handshake.7356.115675.WLILIGUWIWDITSQJ: unknown error code (141)
[0702/125406.781059:FATAL:child_port_handshake.cc(111)] Check failed: server_port.is_valid().
0   crashpad_handler                    0x000000010aec16bc base::debug::StackTrace::StackTrace(unsigned long) + 28
1   crashpad_handler                    0x000000010aeae9c1 logging::LogMessage::~LogMessage() + 225
2   crashpad_handler                    0x000000010aecb394 crashpad::ChildPortHandshake::RunServerForFD(base::ScopedGeneric<int, base::internal::ScopedFDCloseTraits>, crashpad::ChildPortHandshake::PortRightType) + 516
3   crashpad_handler                    0x000000010ae9d876 crashpad::HandlerMain(int, char**, std::__1::vector<std::__1::unique_ptr<crashpad::UserStreamDataSource, std::__1::default_delete<crashpad::UserStreamDataSource> >, std::__1::allocator<std::__1::unique_ptr<crashpad::UserStreamDataSource, std::__1::default_delete<crashpad::UserStreamDataSource> > > > const*) + 4790
4   libdyld.dylib                       0x00007fff989965ad start + 1
Cc: scottmg@chromium.org jperaza@chromium.org
 Issue 862137  has been merged into this issue.
This has been clear on https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Mac10.12%20Tests since 2018-07-10 10:17 PM (PDT)

and similar for 10.11; not sure what the fix was, but I think we can close.

Status: Fixed (was: Available)
Status: Available (was: Fixed)
I doubt that this is actually fixed; I found an instance on a run going back to July 2, as illustrated in c#6, and I suspect it goes back earlier. My guess is that we just hit a string of non-failing runs, which there are throughout the last 200 runs of each of these bots. I would guess that the problem hasn't actually gone away.
Labels: -Sheriff-Chromium
Since this isn't currently happening, I'm going to at least remove this from the sheriff queue.
This is back on Mac10.13 this time: 

https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Mac10.13%20Tests/4810

Nothing in the CL range there strikes me as the cause
Status: Closed (was: Available)
Closing this in favor of  issue 828031 .

Sign in to add a comment