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

Reply via email to