Issue 36013: test_signal fails in AMD64 Debian PGO 3.x (original) (raw)

Created on 2019-02-16 23:07 by pablogsal, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
19592 roufique7,2019-02-16 23:48
Pull Requests
URL Status Linked Edit
PR 11902 merged gregory.p.smith,2019-02-17 00:27
Messages (7)
msg335729 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2019-02-16 23:07
test_signal fails in AMD64 Debian PGO 3.x: == Tests result: FAILURE then FAILURE == 406 tests OK. 10 slowest tests: - test_concurrent_futures: 2 min 37 sec - test_multiprocessing_spawn: 2 min 3 sec - test_multiprocessing_forkserver: 1 min 28 sec - test_multiprocessing_fork: 1 min 17 sec - test_gdb: 46 sec 874 ms - test_asyncio: 46 sec 166 ms - test_tools: 37 sec 582 ms - test_io: 35 sec 518 ms - test_tokenize: 34 sec 631 ms - test_subprocess: 34 sec 302 ms 1 test failed: test_signal 13 tests skipped: test_devpoll test_ioctl test_kqueue test_msilib test_ossaudiodev test_startfile test_tix test_tk test_ttk_guionly test_winconsoleio test_winreg test_winsound test_zipfile64 https://buildbot.python.org/all/#/builders/47/builds/2251/steps/4/logs/stdio test_valid_signals (test.test_signal.WindowsSignalTests) ... skipped 'Windows specific' ====================================================================== FAIL: test_keyboard_interrupt_communicated_to_shell (test.test_signal.PosixTests) KeyboardInterrupt exits such that shells detect a ^C. ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.nondebug/build/Lib/test/test_signal.py", line 121, in test_keyboard_interrupt_communicated_to_shell self.assertNotIn(b"TESTFAIL", process.stdout) AssertionError: b'TESTFAIL' unexpectedly found in b'TESTFAIL using bash 4.4.12(1)-release\n' ---------------------------------------------------------------------- This may be related to PR11862
msg335732 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2019-02-16 23:32
This means either that the bash minimum version needs upping to a patch level or that the test is actually flaky and both I and all of the CI got lucky when running it (i'm not actually sure if any of the CI actually ran this test or just skipped it - the test.regrtest output on CI is never verbose so I can't tell). if i can't untangle bash versions, the other alternative is to just not bother with a shell based test for this as it is too complicated due to depending on exact behaviors of a shell testing an interactive feature in fake interactive mode. changing the child process to just "raise KeyboardInterrupt" as is done in the equivalent Windows test is sufficient.
msg335735 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2019-02-16 23:57
I scheduled a rebuild to check if the failure is consistent.
msg335736 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2019-02-17 00:14
I have tested in Ubuntu with the same version of bash 4.4.12(1)-release and the test succeeds: d7d8cf5d89bf">root@d7d8cf5d89bf:/src# echo $BASH_VERSION 4.4.12(1)-release d7d8cf5d89bf">root@d7d8cf5d89bf:/src# ./python -m test test_signal -m test_keyboard_interrupt_communicated_to_shell Run tests sequentially 0:00:00 load avg: 0.77 [1/1] test_signal b'4.4.12(1)-release\n' [4, 4] == Tests result: SUCCESS == 1 test OK. Total duration: 74 ms Tests result: SUCCESS
msg335737 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2019-02-17 00:15
testing on my end with various bash versions shows that bash 4.3.0 and 4.4.0 and 5.0.0 all work fine on my linux and macos systems. caveat, i'm launching regrtest from a login shell (in case that influences child bash processes behavior). i'm going to abandon bash for this test.
msg335739 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2019-02-17 00:22
Could it be a race condition the signal delivery? Technically, the process sends itself a signal and never waits for it, it just exits. The signal can arrive after the process has exited normally. Or I am missing something obvious in this reasoning?
msg335741 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2019-02-17 01:22
New changeset 414c625a7ea58943f0b1bc79d095d667d78db013 by Gregory P. Smith in branch 'master': bpo-36013: delete fragile interactive shell SIGINT test (GH-11902) https://github.com/python/cpython/commit/414c625a7ea58943f0b1bc79d095d667d78db013
History
Date User Action Args
2022-04-11 14:59:11 admin set github: 80194
2019-02-17 01:23:17 gregory.p.smith set status: open -> closedresolution: fixedstage: patch review -> resolved
2019-02-17 01:22:43 gregory.p.smith set messages: +
2019-02-17 00:27:34 gregory.p.smith set keywords: + patchstage: needs patch -> patch reviewpull_requests: + <pull%5Frequest11928>
2019-02-17 00:22:52 pablogsal set messages: +
2019-02-17 00:15:04 gregory.p.smith set messages: +
2019-02-17 00:14:59 pablogsal set messages: +
2019-02-16 23:57:16 pablogsal set messages: +
2019-02-16 23:48:14 roufique7 set files: + 19592
2019-02-16 23:32:01 gregory.p.smith set assignee: gregory.p.smithtype: behaviormessages: + stage: needs patch
2019-02-16 23:07:40 pablogsal create