Charles-François Natali neolo...@free.fr added the comment:
Patch attached:
- a new process is spawned (using assert_python_ok()) to avoid
undefined behavior (and crash on FreeBSD)
- I've kept SIGUSR1 default handler, because, as noted in
http://bugs.python.org/issue8407#msg138066 , there can
Roundup Robot devnull@devnull added the comment:
New changeset d07d0afea9a7 by Victor Stinner in branch 'default':
Issue #12316: Fix sigwait() test using threads
http://hg.python.org/cpython/rev/d07d0afea9a7
--
nosy: +python-dev
___
Python tracker
STINNER Victor victor.stin...@haypocalc.com added the comment:
Patch attached
The patch looks correct, but only FreeBSD 6.4 can tell us if it works or not,
so I commited your new version of the test.
I inlined check_sigwait() because the function was only called by
test_sigwait().
STINNER Victor victor.stin...@haypocalc.com added the comment:
test_signal passed in build #1577 of x86 FreeBSD 6.4 3.x: I close this issue.
Thanks neologix!
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
New submission from Charles-François Natali neolo...@free.fr:
http://www.python.org/dev/buildbot/all/builders/x86 FreeBSD 6.4
3.x/builds/1570/steps/test/logs/stdio
[ 29/356] test_signal
Fatal error 'mutex is on list' at line 540 in file
/usr/src/lib/libpthread/thread/thr_mutex.c (errno = 22)
STINNER Victor victor.stin...@haypocalc.com added the comment:
In a multi-threaded program, we're only allowed to call async-safe
functions between fork() and exec() in the child process
Oh, I don't know that. The test should be modified to create a new clean Python
process using subprocess
