Python 3.12 testing

Sat Apr 19 02:11:31 GMT 2025

I attached the requested strace of the failing python invocation:
strace -o python312-test-threading.strace ./python -X dev -m 
test.test_threading BarrierTests.test_abort
I also tried to narrow down which part of the code was at fault,
but my attempts to re-create the crash in C failed, as did
copying the test to a new python file (both completed successfully).
python -m pip install --no-cache --ignore-installed pip wheel setuptools
also usually crashes silently (and hung in previous versions), so
I tried running that under gdb.  That produced a crash, again
with the first frame reported as null, but this time with a
traceback, again through pthread::exit.  The two frames after that which
reported the segfault are pthread_testcancel and pthread_rwlock_wrlock,
which at least gives me somewhere to focus for trying to create an STC.
I also attached cygcheck-srv.log, in case there's something obvious there
On 4/6/2025 4:32 PM, dwes1 wrote:
> To the Python maintainer and anyone else testing Python 3.12:
>> A few weeks ago, the python developer requested help with evaluating 
> the Python 3.12 release.
> I downloaded the python312-test package, and worked out that
> python -m test.test_threading -v
> failed during the second test in the file, sometimes with an immediate 
> segfault, sometimes by hanging
> until I tried to attach gdb, which immediately reported an empty stack 
> and a null stack pointer.
>> Adding print calls to the test narrowed the point of failure to some 
> time during thread cleanup,
> so I ran the test under gdb, adding breakpoints to pthread_exit and 
> pthread::exit, which caught
> the test before the segfault, and displayed a stack working back to 
> pthread_wrapper, whose caller
> was set to null.  Stepping through the function eventually reached a 
> call to ExitThread, then the
> segfault with no reported stack.
>> My current guess is that ExitThread somehow returns, leading to 
> control falling off the end of
> pthread_wrapper and failing to return.  (This is rather more sensible 
> than my previous guess
> that Python had somehow managed to call the NULL pointer recursively, 
> and not noticed until
> gdb took a look at things)  I suppose I could try to compile Cygwin 
> with an error message after
> ExitThread to see if that prints, but I am otherwise out of ideas.
>> I first checked this around January on a Windows 10 machine from 2016, 
> then on a machine from
> within the last year that is says it is also Windows 10.
>> I hope this helps
>-------------- next part --------------
A non-text attachment was scrubbed...
Name: cygcheck-srv-filtered.log.xz
Type: application/x-compressed
Size: 35276 bytes
Desc: not available
URL: <https://cygwin.com/pipermail/cygwin/attachments/20250418/f2500d95/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: python312-test-threading-filtered.strace.xz
Type: application/x-compressed
Size: 208904 bytes
Desc: not available
URL: <https://cygwin.com/pipermail/cygwin/attachments/20250418/f2500d95/attachment-0003.bin>