This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: test_signal fails in AMD64 Debian PGO 3.x
Type: behavior Stage: resolved
Components: Tests Versions: Python 3.8
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: gregory.p.smith Nosy List: gregory.p.smith, pablogsal
Priority: normal Keywords: patch

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

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:
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

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/", 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

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
[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)
Date User Action Args
2022-04-11 14:59:11adminsetgithub: 80194
2019-02-17 01:23:17gregory.p.smithsetstatus: open -> closed
resolution: fixed
stage: patch review -> resolved
2019-02-17 01:22:43gregory.p.smithsetmessages: + msg335741
2019-02-17 00:27:34gregory.p.smithsetkeywords: + patch
stage: needs patch -> patch review
pull_requests: + pull_request11928
2019-02-17 00:22:52pablogsalsetmessages: + msg335739
2019-02-17 00:15:04gregory.p.smithsetmessages: + msg335737
2019-02-17 00:14:59pablogsalsetmessages: + msg335736
2019-02-16 23:57:16pablogsalsetmessages: + msg335735
2019-02-16 23:48:14roufique7setfiles: + 19592
2019-02-16 23:32:01gregory.p.smithsetassignee: gregory.p.smith
type: behavior
messages: + msg335732
stage: needs patch
2019-02-16 23:07:40pablogsalcreate