[issue35425] test_eintr fails randomly on AMD64 FreeBSD 10-STABLE Non-Debug 3.7: TypeError: 'int' object is not callable

STINNER Victor added the comment: I didn't see this issue recently, so I close it. -- resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker

[issue35425] test_eintr fails randomly on AMD64 FreeBSD 10-STABLE Non-Debug 3.7: TypeError: 'int' object is not callable

STINNER Victor added the comment: Another recent failure: https://buildbot.python.org/all/#/builders/167/builds/488 ... test_kqueue (__main__.SelectEINTRTest) ... ok test_poll (__main__.SelectEINTRTest) ... ok test_select (__main__.SelectEINTRTest) ... test_all (test.test_eintr.EINTRTests)

[issue35425] test_eintr fails randomly on AMD64 FreeBSD 10-STABLE Non-Debug 3.7: TypeError: 'int' object is not callable

Pablo Galindo Salgado added the comment: I logged in into the buildbot and try to reproduce that. After 230 iterations of `test_eintr` I cannot reproduce the signal problem. Maybe this is an interaction with some other test -- ___ Python

[issue35425] test_eintr fails randomly on AMD64 FreeBSD 10-STABLE Non-Debug 3.7: TypeError: 'int' object is not callable

Pablo Galindo Salgado added the comment: Could it be that there is another test that is sending SIGALRM but does not disarm the ITIMER_REAL timer before restoring the previous handler? --- TypeError: 'int' object is not callable Can it be that thread.file has some custom

[issue35425] test_eintr fails randomly on AMD64 FreeBSD 10-STABLE Non-Debug 3.7: TypeError: 'int' object is not callable

STINNER Victor added the comment: Sometimes a test is killed by SIGALRM (signal 14). I don't understand how it can happen, since test_eintr always disarm the ITIMER_REAL timer before restoring the old signal handler (which kills the process when SIGARLM is received).

[issue35425] test_eintr fails randomly on AMD64 FreeBSD 10-STABLE Non-Debug 3.7: TypeError: 'int' object is not callable

New submission from STINNER Victor : I don't understand the error, it doesn't make sense. It *seems* like faulthandler.cancel_dump_traceback_later attribute has been set to an int, but I don't see how it could be possible. Or the call raises the TypeError? But the call can be summarized to: