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) test test_signal failed -- Traceback (most recent call last): File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_signal.py", line 669, in test_sigwait_thread self.check_sigwait(test, signal.SIGUSR1) File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_signal.py", line 632, in check_sigwait self.assertEqual(os.waitpid(pid, 0), (pid, 0)) AssertionError: Tuples differ: (50592, 134) != (50592, 0) First differing element 1: 134 0 - (50592, 134) ? ^^^ + (50592, 0) ? ^ """ Fatal error 'mutex is on list' at line 540 in file /usr/src/lib/libpthread/thread/thr_mutex.c (errno = 22) In a multi-threaded program, we're only allowed to call async-safe functions between fork() and exec() in the child process (well, taken literaly this means we shouldn't run Python at all after fork...). It looks like FreeBSD 6.4 doesn't like new threads after fork() : http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2008-03/msg00108.html test_sigwait_thread should either be skipped on FreeBSD 6 (it seems to pass on FreeBSD 7), or removed altogether. ---------- components: Tests messages: 138138 nosy: haypo, neologix priority: normal severity: normal status: open title: test_signal: test_sigwait_thread failure on FreeBSD 6.4 buildbot type: behavior versions: Python 3.3 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12316> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com