While unlikely to be the issue, there was a problem with test_profiling aborting on my buildbot back from Dec 8-11, due to an interaction with an earlier commit and auditing (fixed by Victor in https://github.com/python/cpython/issues/142627).
What was happening is that when test_profiling aborted, it stranded one or two processes that would hang around forever and eat up CPU. The most common one was a process (owned by init) running a command line python -c script (involving ExpensiveGarbage()) that seemed stuck with their sockets in CLOSE_WAIT presumably in some sort of tight loop burning CPU. Over time they ate up some other sort of resource as every build would start failing with odd errors. In that case, the issue was not directly related to test_profiling, which may or may not be the case here, but I do think something in that test suite is not friendly if the process aborts mid-test without cleanup. It was a SIGABRT in my case, and looks like SIGSEGV here in your build, but probably the same result. While debugging the issue I did in fact implement a monitor script to kill off any such processes, but I haven't seen anything show up on my buildbot since the 12th. And it looks like test_profiling was fine on my equivalent build matching your 12988, so not quite sure what's to make of that. -- David On Fri, Dec 19, 2025 at 3:29 PM Chris Angelico via Python-Buildbots < [email protected]> wrote: > A couple of times now, I've seen my buildbot consuming a constant 100% > CPU, despite not having an active build. It was a Python process > running inline code, and the code itself looked like it came from > Lib/test/test_profiling/test_sampling_profiler/test_integration.py > (specifically, I think it's the test_script as used by > test_subprocess, not the cli_test_script). A recent build seems to > have had a failure in that test: > > > https://buildbot.python.org/all/#/builders/345/builds/12988/steps/6/logs/warnings__3_ > > https://buildbot.python.org/all/#/builders/345/builds/12988/steps/6/logs/stdio > > which ended with a segfault. > > Is this something that's likely to happen again in the future, and > thus should I devise a script that will find and kill rogue processes? > Or is this preventable within the test suite? > > ChrisA > _______________________________________________ > Python-Buildbots mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3//lists/python-buildbots.python.org > Member address: [email protected] > _______________________________________________ Python-Buildbots mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3//lists/python-buildbots.python.org Member address: [email protected]
