Bug#822325: [Pkg-rust-maintainers] Bug#822325: rustc: FTBFS in testing: test fail
On Sat, 14 May 2016, Luca BRUNO wrote: > I just reproduced it via `systemd-run --scope -p TasksMax=512 > ./tcp-stress`. Part of it is due to the tcp-stress test not > checking for spawned thread, I've just submitted a PR to make that > failure explicit: https://github.com/rust-lang/rust/pull/33640 Thanks a lot! Even if this is officially more a bug in systemd than a bug in rustc, it's always a good thing that error messages are helpful and explain what's the problem. > If your sbuild is running as a daemon or in any other dedicated way, I think > you should ask for its TasksMax setting to be increased. Yes, or just wait for syetemd 229-6 to enter testing. The old default for TasksMax was not good for everybody (this FTBFS problem is an example) so they have set it to infinity in systemd. So I did the same in my hand-made autobuilder (which is triggered by cron) to avoid this happening again. Thanks.
Bug#822325: [Pkg-rust-maintainers] Bug#822325: rustc: FTBFS in testing: test fail
forwarded 822325 https://github.com/rust-lang/rust/pull/33640 thanks On Saturday, May 14, 2016 02:52:55 PM Santiago Vila wrote: > > In both cases the problem went away by setting > DefaultTasksMax=infinity in /etc/systemd/system.conf. Good catch! I was aware of it, but didn't come to my mind in this context. > So I tried doing that with rustc and the problem went away as well. > > For reference, this was the setting in systemd which most likely was > to blame for this: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823530 > > This setting has been changed in systemd yesterday and it will reach > testing in four days, so if you still want to reproduce this in rustc > in testing (using the kernel in testing), maybe you could. I was not able to reproduce it as I was building from a user session, while you are probably outside of it (system service or a naked shell). I just reproduced it via `systemd-run --scope -p TasksMax=512 ./tcp-stress`. Part of it is due to the tcp-stress test not checking for spawned thread, I've just submitted a PR to make that failure explicit: https://github.com/rust-lang/rust/pull/33640 If your sbuild is running as a daemon or in any other dedicated way, I think you should ask for its TasksMax setting to be increased. Ciao, Luca signature.asc Description: This is a digitally signed message part.
Bug#822325: rustc: FTBFS in testing: test fail
close 822325 severity 822325 important affects 823530 rustc thanks > This looks like an artifact due to your build environment, > [...] > > this looks like just some test instability on an emulated environment, > [...] I really think this was not the case here, as I have now a more than likely explanation for the FTBFS bug. Your comments about the tests being heavily threaded made me to remember that I filed two bugs very similar to this one: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823553 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823604 (Note: I'm setting this one to "important" only to be in sync with those two bugs, as it was a FTBFS bug after all, but I'm also closing it at the same time). In both cases the problem went away by setting DefaultTasksMax=infinity in /etc/systemd/system.conf. So I tried doing that with rustc and the problem went away as well. For reference, this was the setting in systemd which most likely was to blame for this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823530 This setting has been changed in systemd yesterday and it will reach testing in four days, so if you still want to reproduce this in rustc in testing (using the kernel in testing), maybe you could. But for all purposes I consider this issue solved. Thanks a lot.
Bug#822325: rustc: FTBFS in testing: test fail
severity 822325 minor tags 822325 + moreinfo thanks On Sat, 23 Apr 2016 14:33:48 +0200 (CEST) Santiago Vila wrote: > This package currently fails to build from source in stretch. > > -- > executing x86_64-unknown-linux-gnu/test/run-pass/tcp-stress.stage2-x86_64- > unknown-linux-gnu > --stdout-- > > --stderr-- > thread '' panicked at 'called `Result::unwrap()` on an `Err` value: > RecvError', src/libcore/result.rs:746 > > -- > > The build was made on two different QEMU virtual machines with 4GB RAM > and 4GB swap, running stretch, using sbuild. This looks like an artifact due to your build environment, as I just tried building on a physical stretch amd64 machine and all tests pass: """ summary of 50 test runs: 10108 passed; 0 failed; 88 ignored; 0 measured """ A couple of ideas regarding this test: * it is heavily threaded, it may trigger some data races in qemu * it may be slow to run and thus timing out. Can you try increasing the timeout at the top of src/test/run-pass/tcp-stress.rs? * It may be dropping the sender to early. Can you try moving the `drop(tx)` just before `process::exit(0)`? Anyway, this looks like just some test instability on an emulated environment, and not a real regression. Thus I'm downgrading it. Can you please try the small changes I suggested above? If so, it may be worth reporting it directly to upstream. Ciao, Luca
Bug#822325: rustc: FTBFS in testing: test fail
Package: src:rustc Version: 1.8.0+dfsg1-1 Severity: serious Dear maintainer: This package currently fails to build from source in stretch. -- executing x86_64-unknown-linux-gnu/test/run-pass/tcp-stress.stage2-x86_64-unknown-linux-gnu --stdout-- --stderr-- thread '' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', src/libcore/result.rs:746 stack backtrace: 1: 0x7fc8b2cc1900 - sys::backtrace::tracing::imp::write::h09d7a562cdce3ef9Xcv 2: 0x7fc8b2ccac0b - panicking::default_handler::_$u7b$$u7b$closure$u7d$$u7d$::closure.44519 3: 0x7fc8b2cca7d8 - panicking::default_handler::hf7fdb8082bcb0f80lSz 4: 0x7fc8b2c90796 - sys_common::unwind::begin_unwind_inner::hfa667eeafdcc5750g1t 5: 0x7fc8b2c91178 - sys_common::unwind::begin_unwind_fmt::h7ecf9e1791369861m0t 6: 0x7fc8b2cbf391 - rust_begin_unwind 7: 0x7fc8b2d0889f - panicking::panic_fmt::h62b9bbe5858e3d52lcM 8: 0x55b2984f6356 - result::unwrap_failed::h10913119902250946022 9: 0x55b2984f05f5 - main::h6d9484c71b91fae9naa 10: 0x7fc8b2cca244 - sys_common::unwind::try::try_fn::h6973910833277520139 11: 0x7fc8b2cbf31b - __rust_try 12: 0x7fc8b2cc9ea1 - rt::lang_start::h5628b9e1fb87c585rKz 13: 0x7fc8b244460f - __libc_start_main 14: 0x55b2984ed038 - _start 15:0x0 - -- The build was made on two different QEMU virtual machines with 4GB RAM and 4GB swap, running stretch, using sbuild. The full build log is attached. Thanks. rustc_1.8.0+dfsg1-1_amd64-20160423-1246.gz Description: application/gzip
