[issue12469] test_faulthandler failures on FreeBSD 6

STINNER Victor report at bugs.python.org
Sat Jul 2 02:15:59 CEST 2011

STINNER Victor <victor.stinner at 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)

Then test_signal.test_pthread_kill_main_thread() should be skipped or patched for freebsd6.


Python tracker <report at bugs.python.org>

More information about the Python-bugs-list mailing list