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.

classification
Title: test_multiprocessing_spawn crashed on AMD64 Windows8.1 Non-Debug 3.x buildbot
Type: crash Stage: resolved
Components: Library (Lib), Tests, Windows Versions: Python 3.7
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: davin, paul.moore, steve.dower, tim.golden, twouters, vstinner, zach.ware
Priority: normal Keywords:

Created on 2017-04-26 12:54 by vstinner, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (6)
msg292337 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-04-26 12:54
http://buildbot.python.org/all/builders/AMD64%20Windows8.1%20Non-Debug%203.x/builds/670/steps/test/logs/stdio

0:05:37 [255/404/1] test_multiprocessing_spawn crashed (Exit code 3221225477)
Windows fatal exception: access violation

Current thread 0x00001644 (most recent call first):
  File "D:\buildarea\3.x.ware-win81-release\build\lib\test\_test_multiprocessing.py", line 3997 in ManagerMixin
  File "D:\buildarea\3.x.ware-win81-release\build\lib\test\_test_multiprocessing.py", line 3988 in <module>
  File "<frozen importlib._bootstrap>", line 205 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 679 in exec_module
  File "<frozen importlib._bootstrap>", line 655 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 950 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 961 in _find_and_load
  File "D:\buildarea\3.x.ware-win81-release\build\lib\test\test_multiprocessing_spawn.py", line 2 in <module>
  File "<frozen importlib._bootstrap>", line 205 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 679 in exec_module
  File "<frozen importlib._bootstrap>", line 655 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 950 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 961 in _find_and_load
  File "<frozen importlib._bootstrap>", line 978 in _gcd_import
  File "D:\buildarea\3.x.ware-win81-release\build\lib\importlib\__init__.py", line 127 in import_module
  File "D:\buildarea\3.x.ware-win81-release\build\lib\test\libregrtest\runtest.py", line 152 in runtest_inner
  File "D:\buildarea\3.x.ware-win81-release\build\lib\test\libregrtest\runtest.py", line 119 in runtest
  File "D:\buildarea\3.x.ware-win81-release\build\lib\test\libregrtest\runtest_mp.py", line 71 in run_tests_slave
  File "D:\buildarea\3.x.ware-win81-release\build\lib\test\libregrtest\main.py", line 470 in _main
  File "D:\buildarea\3.x.ware-win81-release\build\lib\test\libregrtest\main.py", line 463 in main
  File "D:\buildarea\3.x.ware-win81-release\build\lib\test\libregrtest\main.py", line 527 in main
  File "D:\buildarea\3.x.ware-win81-release\build\lib\test\regrtest.py", line 46 in _main
  File "D:\buildarea\3.x.ware-win81-release\build\lib\test\regrtest.py", line 50 in <module>
  File "D:\buildarea\3.x.ware-win81-release\build\lib\runpy.py", line 85 in _run_code
  File "D:\buildarea\3.x.ware-win81-release\build\lib\runpy.py", line 193 in _run_module_as_main

Note: same crash in test_multiprocessing_fork, even if Windows has no os.fork(): the crash occurs at lib\test\test_multiprocessing_fork.py:2 "import test._test_multiprocessing", before check if os.fork() exists.
msg292338 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-04-26 13:06
The crash is probably random. I looked at the last 250 builds. Since build 421, the first crash occurred at build 578 (commit a00c3fd12d421e41b769debd7df717d17b0deed5, no idea if it's related):

http://buildbot.python.org/all/builders/AMD64%20Windows8.1%20Non-Debug%203.x/builds/578/

I found 8 test_multiprocessing_spawn crashes in builds:

* 578
* 579
* 659
* 660
* 661
* 664
* 665
* 670
msg292339 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-04-26 13:11
Current thread 0x00001644 (most recent call first):
  File "D:\buildarea\3.x.ware-win81-release\build\lib\test\_test_multiprocessing.py", line 3997 in ManagerMixin

Line 3997 is:
   Condition = property(operator.attrgetter('manager.Condition'))

I don't understand how creating operator.attrgetter() or property() object can crash? Maybe the memory was corrupted before?

Extract of _test_multiprocessing.py around this line:

class ManagerMixin(object):
    TYPE = 'manager'
    Process = multiprocessing.Process
    Queue = property(operator.attrgetter('manager.Queue'))
    JoinableQueue = property(operator.attrgetter('manager.JoinableQueue'))
    Lock = property(operator.attrgetter('manager.Lock'))
    RLock = property(operator.attrgetter('manager.RLock'))
    Semaphore = property(operator.attrgetter('manager.Semaphore'))
    BoundedSemaphore = property(operator.attrgetter('manager.BoundedSemaphore'))
    Condition = property(operator.attrgetter('manager.Condition'))
    Event = property(operator.attrgetter('manager.Event'))
    Barrier = property(operator.attrgetter('manager.Barrier'))
    Value = property(operator.attrgetter('manager.Value'))
    Array = property(operator.attrgetter('manager.Array'))
    list = property(operator.attrgetter('manager.list'))
    dict = property(operator.attrgetter('manager.dict'))
    Namespace = property(operator.attrgetter('manager.Namespace'))
msg292341 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-04-26 13:23
I also checked the last 250 builds of AMD64 Windows8 3.x: test_multiprocessing_spawn never crashed.

http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x

We got 8 crashed on "AMD64 Windows8.1 Non-Debug 3.x", but 0 crash on "AMD64 Windows8 3.x" (similar Windows version, but it's a different buildbot slave, so different hardware, version, etc.)... So *maybe* it's related to the commit a00c3fd12d421e41b769debd7df717d17b0deed5 and the issue #29941 since this patch changed the behaviour of Python compiled in release mode.
msg292359 - (view) Author: Thomas Wouters (twouters) * (Python committer) Date: 2017-04-26 14:55
Eh, commit a00c3fd12d421e41b769debd7df717d17b0deed5 wasn't supposed to affect any behaviour in release builds, just in non-debug builds *with asserts enabled*, and only in making them build. 

(There is a bug in that commit that was fixed right after,  commit 06bb4873d6a9ac303701d08a851d6cd9a51e02a3, but there shouldn't be any behavioural change since that went in.)

What kind of behaviour change do you think the change caused?
msg292767 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-05-02 14:40
Sadly, the random issue didn't reoccur in the following 13 builds. So I close the issue. I will reopen it if I see the crash again.
History
Date User Action Args
2022-04-11 14:58:45adminsetgithub: 74355
2017-05-02 14:40:04vstinnersetstatus: open -> closed
resolution: out of date
messages: + msg292767

stage: resolved
2017-04-26 14:55:30twouterssetnosy: + twouters
messages: + msg292359
2017-04-26 13:23:34vstinnersetmessages: + msg292341
2017-04-26 13:11:50vstinnersetmessages: + msg292339
2017-04-26 13:06:11vstinnersetmessages: + msg292338
2017-04-26 12:54:26vstinnercreate