New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test_multiprocessing_spawn dumps core in AMD64 FreeBSD CURRENT Shared 3.x #80295
Comments
OK (skipped=32) https://buildbot.python.org/all/#/builders/168/builds/632/steps/4/logs/stdio |
Another failure: |
Another example of this, same bot: |
After some investigation, this turns out to be more complicated, as this 'python.core' turns to be a core dumped from some of the processes spawned by test_multiprocessing_spawn. So the real problem is that test_multiprocessing_spawn segfaults, as in https://bugs.python.org/issue36116. I think this may be the same underlying problem. I will change the title to reflect this. |
I managed to access the core file and this is the traceback: Thread 3 (LWP 100629): Thread 2 (LWP 101669): Thread 1 (LWP 100922): |
Apparently is the Thread 1 the one that is causing the core dump |
This is the state of the thread interpreter: gdb) p tstate |
I can reproduce the crash on my FreeBSD 12 VM: vstinner@freebsd$ ./python -m test --fail-env-changed test_multiprocessing_spawn -v FAIL: test_mymanager_context_prestarted (test.test_multiprocessing_spawn.WithManagerTestMyManager) Traceback (most recent call last):
File "/usr/home/vstinner/prog/python/master/Lib/test/_test_multiprocessing.py", line 2754, in test_mymanager_context_prestarted
self.assertEqual(manager._process.exitcode, 0)
AssertionError: -10 != 0 Warning -- files was modified by test_multiprocessing_spawn |
Interesting, I tried several hours to reproduce the crash on the buildbot itself manually and I could not do it. |
I recently (Feb 25) fixed the config of this slow buildbot to change the timeout from 15 min to 20 min: python/buildmaster-config@37cf09c It seems like there is a correlation between this buildbot config change and the buildbot starting to create a coredump file. The test started to create a core dump around build 624, Feb 25. -- With coredump. Warning -- files was modified by test_multiprocessing_spawn: https://buildbot.python.org/all/#/builders/168/builds/624 -- Without coredump: fail but no coredump. ERROR: test_shared_memory_SharedMemoryManager_basics (test.test_multiprocessing_forkserver.WithProcessesTestSharedMemory) https://buildbot.python.org/all/#/builders/168/builds/617 |
I set the priority to release blocker to remind to fix this regression. I guess that it's the same bug than bpo-36116, but since it's a different OS (FreeBSD / Windows), I prefer to continue to use separated issues. |
Can you paste traceback of the dump that you were able to generate in your FreeBSD? I wonder if you can get the symbols that the one I pasted were missing (likely in libthr.so). |
Example of crash:
Problem: PyThreadState of Thread 1 is corrupted: its memory has been freed. Thread 1 got the crash (gdb) p tstate (gdb) p _PyRuntime.gilstate.tstate_current (gdb) thread apply all where Thread 3 (LWP 100714): Thread 2 (LWP 100120): Thread 1 (LWP 100696): |
Sometimes, I can reproduce the crash using: Using this file: test.test_multiprocessing_spawn.WithThreadsTestQueue.test_timeout It seems like the following test is enough to creates a coredump: test.test_multiprocessing_spawn.WithThreadsTestManagerRestart.test_rapid_restart Problem: it's really hard to write a *reliable* script/method to trigger the crash. This race condition is very well hidden! |
Currently guilty: commit ef4ac96
|
Ok, I confirm that the commit ef4ac96 introduced a regression in test.test_multiprocessing_spawn.WithThreadsTestManagerRestart.test_rapid_restart. |
This is resolved with #56368, no? |
I was waiting to see if buildbot workers feel better. It's the case, so I close the issue. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: