Skip to content

std: Ignore test_process_mask on OSX #27516

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
Merged
merged 1 commit into from
Aug 10, 2015
Merged

std: Ignore test_process_mask on OSX #27516

merged 1 commit into from
Aug 10, 2015
+4 −0

Conversation

alexcrichton
Copy link
Member

The investigation into #14232 discovered that it's possible that signal delivery
to a newly spawned process is racy on OSX. This test has been failing spuriously
on the OSX bots for some time now, so ignore it as we don't currently know a
solution and it looks like it may be out of our control.

@alexcrichton
std: Ignore test_process_mask on OSX
4ac7e87 
The investigation into rust-lang#14232 discovered that it's possible that signal delivery
to a newly spawned process is racy on OSX. This test has been failing spuriously
on the OSX bots for some time now, so ignore it as we don't currently know a
solution and it looks like it may be out of our control.
@alexcrichton
Copy link
Member Author

r? @brson

@rust-highfive rust-highfive assigned brson and unassigned nikomatsakis Aug 4, 2015
@rust-highfive
Copy link
Contributor

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

@oli-obk
Copy link
Contributor

oli-obk commented Aug 4, 2015

I can deterministically cause this on linux if I run make check from the atom editor through the build package.

@alexcrichton
Copy link
Member Author

@oli-obk can you elaborate a little more? What target triple are you using? Do you have optimized or unoptimized tests? Do you have some logs I could look at?

If this is happening elsewhere then there may be a legit bug, I just haven't been able to reproduce on linux yet.

@oli-obk
Copy link
Contributor

oli-obk commented Aug 4, 2015

build-atom runs make check inside sh. Maybe this can be reproduced by manually calling it inside an sh shell, I'll try to do that once I hit the failure again from inside atom.

cfg: version 1.3.0-dev (1b5df5a79 2015-07-29)
cfg: build triple x86_64-unknown-linux-gnu
cfg: host triples x86_64-unknown-linux-gnu
cfg: target triples x86_64-unknown-linux-gnu
cfg: host for x86_64-unknown-linux-gnu is x86_64
cfg: os for x86_64-unknown-linux-gnu is unknown-linux-gnu
cfg: good valgrind for x86_64-unknown-linux-gnu is 1
cfg: using CC=gcc (CFG_CC)

I ran a ./configure without arguments before. Running the compilation and tests right now. I'll post the log once I hit the test.

@oli-obk
Copy link
Contributor

oli-obk commented Aug 4, 2015

Full error:

Executing with sh: make  check TESTNAME=test_process_mask
cfg: version 1.3.0-dev (1b5df5a79 2015-07-29)
cfg: build triple x86_64-unknown-linux-gnu
cfg: host triples x86_64-unknown-linux-gnu
cfg: target triples x86_64-unknown-linux-gnu
cfg: host for x86_64-unknown-linux-gnu is x86_64
cfg: os for x86_64-unknown-linux-gnu is unknown-linux-gnu
cfg: good valgrind for x86_64-unknown-linux-gnu is 1
cfg: using CC=gcc (CFG_CC)
cfg: disabling valgrind run-pass tests
cfg: no xelatex found, disabling LaTeX docs
cfg: no pandoc found, omitting PDF and EPUB docs
cfg: including test rules
cfg: javac not available, skipping lexer test...
run: x86_64-unknown-linux-gnu/stage2/test/stdtest-x86_64-unknown-linux-gnu

running 1 test
thread '<unnamed>' panicked at 'assertion failed: ret == 0', src/libstd/sys/unix/process.rs:499
stack backtrace:
   1:     0x7fb91d34e8b3 - sys::backtrace::write::h118c75566581584bLns
   2:     0x7fb91d35735b - panicking::on_panic::hb29e0c92e68b6099Nxx
   3:     0x7fb91d18c67e - rt::unwind::begin_unwind_inner::h16084ed3d9b2a0caBex
   4:     0x7fb91d18c561 - rt::unwind::begin_unwind::h4876894998304443716
   5:     0x7fb91d35203e - sys::process::tests::test_process_mask::h7f10df19f558087a1wv
   6:     0x7fb91d37bc1b - boxed::F.FnBox<A>::call_box::h3137439688241643459
   7:     0x7fb91d37e4a2 - boxed::F.FnBox<A>::call_box::h894454766707528792
   8:     0x7fb91d37c3a9 - rt::unwind::try
::try_fn::h12391789102408719320
   9:     0x7fb91d3aa15f - __rust_try_inner
  10:     0x7fb91d3aa19a - __rust_try
  11:     0x7fb91d3a5497 - rt::unwind::try::inner_try::h4b94860011c08d91AYw
  12:     0x7fb91d37c5c8 - boxed::F.FnBox<A>::call_box::h4082951101316925067
  13:     0x7fb91d3a9311 - sys::thread::Thread::new::thread_start::h866d84d0c1e32215g8v
  14:     0x7fb91cb200a3 - start_thread
  15:     0x7fb91c43704c - clone
  16:                0x0 - <unknown>
thread '<main>' panicked at 'Some tests failed', src/libtest/lib.rs:253
stack backtrace:
test sys::process::tests::test_process_mask ... FAILED

failures:

failures:
    sys::process::tests::test_process_mask

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured

   1:     0x7fb91d3a6d8e - sys::backtrace::write::h3ed48d9b04182c33Cys
   2:     0x7fb91d3aa862 - panicking::on_panic::h252e2f106e1626c84mx
   3:     0x7fb91d39d5ae - rt::unwind::begin_unwind_inner::h90851cc7e0eaffa9H2w
   4:     0x7fb91d35bb61 - rt::unwind::begin_unwind::h9263853665045484523
   5:     0x7fb91d35d51c - test_main::h499a4ab67aa279d2I1a
   6:     0x7fb91d363a93 - test_main_static::h3fd6cc5020f829d7d4a

   7:     0x7fb91d35a8b9 - __test::main::hcea93956d2b72f1aD7x
   8:     0x7fb91d3aa15f - __rust_try_inner
   9:     0x7fb91d3aa19a - __rust_try
  10:     0x7fb91d3ac517 - rt::lang_start::ha3f98d17b257b53b0hx
  11:     0x7fb91c372b44 - __libc_start_main
  12:     0x7fb91d1880f8 - <unknown>
  13:                0x0 - <unknown>
make: *** [tmp/check-stage2-T-x86_64-unknown-linux-gnu-H-x86_64-unknown-linux-gnu-std.ok] Error 101
rust/mk/tests.mk:449: recipe for target 'tmp/check-stage2-T-x86_64-unknown-linux-gnu-H-x86_64-unknown-linux-gnu-std.ok' failed

running it from sh does not cause the failure. I don't know anything about node.js, maybe calling it from that would reproduce the issue.

@alexcrichton
Copy link
Member Author

And this reproduces 100% of the time? Could you walk me through how you're reproducing this? I just ran this test ~100k times concurrently on my linux VM and it never failed...

@oli-obk
Copy link
Contributor

oli-obk commented Aug 4, 2015

Yes, 100% reproducable in atom, 0% reproducable in bash (although I cannot say that I tested that even remotely as thoroughly as you did... * tips hat *)

this is on debian testing, last apt-get upgrade 2 weeks ago

  1. install atom from https://atom.io/
  2. cd to the rust directory
  3. create a file called .atom-build.json with the contents
{
  "cmd": "make",
  "name": "rust",
  "args": [ "check", "TESTNAME=test_process_mask"],
  "sh": true,
  "cwd": "{PROJECT_PATH}",
  "env": {
    "RUST_BACKTRACE": "1",
  },
}
  1. run atom .
  2. edit -> preferences -> install
  3. search for "build", first result should be "Build your current project, directly from Atom" by noseglid
  4. install that package
  5. go to the menu "packages -> build -> build project"

@alexcrichton
Copy link
Member Author

Excellent! I have repro'd as well. I'll try to do some extra investigation tonight and see if I can't figure out what the root cause is, thanks @oli-obk!

@alexcrichton
Copy link
Member Author

OK after some investigation it looks like the case of running the test from atom is orthogonal to this flakiness. It looks like atom at some point sets the signal handler for SIGINT to SIG_IGN, and then this is inherited across processes so the test (which sends a child process SIGINT) doesn't ever successfully deliver the signal, failing the test.

As a result I think the original conclusion, signal delivery to a process after spawn may not work, may still be relevant, so reopening.

@alexcrichton alexcrichton reopened this Aug 5, 2015
@brson
Copy link
Contributor

brson commented Aug 5, 2015

@bors r+

@bors
Copy link
Collaborator

bors commented Aug 5, 2015

📌 Commit 4ac7e87 has been approved by brson

@bors
Copy link
Collaborator

bors commented Aug 6, 2015

⌛ Testing commit 4ac7e87 with merge 426df00...

@bors
Copy link
Collaborator

bors commented Aug 6, 2015

💔 Test failed - auto-mac-64-nopt-t

@alexcrichton
Copy link
Member Author

@bors: retry

bors added a commit that referenced this pull request Aug 10, 2015
@bors
Auto merge of #27516 - alexcrichton:osx-flaky-zomg, r=brson
96a1f40 
The investigation into #14232 discovered that it's possible that signal delivery
to a newly spawned process is racy on OSX. This test has been failing spuriously
on the OSX bots for some time now, so ignore it as we don't currently know a
solution and it looks like it may be out of our control.
@bors
Copy link
Collaborator

bors commented Aug 10, 2015

⌛ Testing commit 4ac7e87 with merge 96a1f40...

@bors
Copy link
Collaborator

bors commented Aug 10, 2015

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt

@bors bors merged commit 4ac7e87 into rust-lang:master Aug 10, 2015
@alexcrichton alexcrichton deleted the osx-flaky-zomg branch August 11, 2015 06:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees

@brson brson

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
6 participants
@alexcrichton @rust-highfive @oli-obk @brson @bors @nikomatsakis