STINNER Victor <victor.stin...@haypocalc.com> added the comment:
> What happens if you create the thread after having registered
> the SIGBUS handler?
I reverted my commit and created the thread after the call to
faulthandler.register(). It changes nothing, the signal handler is still called
"later" sometimes.
> On FreeBSD 6, os.kill(os.getpid(), signum) calls immediatly
> the signal handler before the creation of the first thread (...),
> whereas the signal handler is called "later" (when exactly?) after
> the creation of the first thread (default after my commit).
It looks like a kernel/libc bug. At least, it doesn't conform to POSIX.1-2001.
Extract of the Linux manual page of the kill function (syscall):
"POSIX.1-2001 requires that if a process sends a signal to itself, and the
sending thread does not have the signal blocked, and no other thread has it
unblocked or is waiting for it in sigwait(3), at least one unblocked signal
must be delivered to the sending thread before the kill() returns."
I see two options:
- revert my commit and fix #12392 (test_signal) differently
- skip test_register, test_register_file, test_register_threads and
test_stack_overflow can on freebsd6
I prefer to revert my commit because it introduced an unexpected behaviour on
signal handling. It calls the signal handler later when the process sends a
signal to itself, even if the application don't use threads.
The new fix for #12392 is to ensure that at least one thread was created. We
can for example use the following code at the beginning of test_signal:
if sys.platform in ('freebsd5', 'freebsd6'):
# On FreeBSD6, pthread_kill() doesn't work on the main thread
# before the creation of the first thread
import threading
t = threading.Thread(target=lambda: None)
t.start()
t.join()
Then test_signal.test_pthread_kill_main_thread() should be skipped or patched
for freebsd6.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12469>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
