Hello,

the test_stack_overflow failed on OpenBSD.

Don't hesitate if you need more information.

Details:
$ ./python Lib/test/test_faulthandler.py 
test_disable (__main__.FaultHandlerTests) ... ok
test_dump_traceback (__main__.FaultHandlerTests) ... ok
test_dump_traceback_file (__main__.FaultHandlerTests) ... ok
test_dump_traceback_threads (__main__.FaultHandlerTests) ... ok
test_dump_traceback_threads_file (__main__.FaultHandlerTests) ... ok
test_dump_tracebacks_later (__main__.FaultHandlerTests) ... ok
test_dump_tracebacks_later_cancel (__main__.FaultHandlerTests) ... ok
test_dump_tracebacks_later_file (__main__.FaultHandlerTests) ... ok
test_dump_tracebacks_later_repeat (__main__.FaultHandlerTests) ... ok
test_dump_tracebacks_later_twice (__main__.FaultHandlerTests) ... ok
test_enable_file (__main__.FaultHandlerTests) ... ok
test_enable_single_thread (__main__.FaultHandlerTests) ... ok
test_fatal_error (__main__.FaultHandlerTests) ... ok
test_gil_released (__main__.FaultHandlerTests) ... ok
test_is_enabled (__main__.FaultHandlerTests) ... ok
test_read_null (__main__.FaultHandlerTests) ... ok
test_register (__main__.FaultHandlerTests) ... ok
test_register_chain (__main__.FaultHandlerTests) ... ok
test_register_file (__main__.FaultHandlerTests) ... ok
test_register_threads (__main__.FaultHandlerTests) ... ok
test_sigabrt (__main__.FaultHandlerTests) ... ok
test_sigbus (__main__.FaultHandlerTests) ... ok
test_sigfpe (__main__.FaultHandlerTests) ... ok
test_sigill (__main__.FaultHandlerTests) ... ok
test_sigsegv (__main__.FaultHandlerTests) ... ok
test_stack_overflow (__main__.FaultHandlerTests) ... FAIL
test_unregister (__main__.FaultHandlerTests) ... ok

======================================================================
FAIL: test_stack_overflow (__main__.FaultHandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_faulthandler.py", line 187, in test_stack_overflow
    other_regex='unable to raise a stack overflow')
  File "Lib/test/test_faulthandler.py", line 105, in check_fatal_error
    self.assertRegex(output, regex)
AssertionError: Regex didn't match: '^Fatal Python error: (?:Segmentation fault|Bus error)\n\nCurrent\\ thread\\ XXX:\n  File "<string>", line 3 in <module>$|unable to raise a stack overflow' not found in ''

----------------------------------------------------------------------
Ran 27 tests in 16.938s

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_faulthandler.py", line 551, in <module>
    test_main()
  File "Lib/test/test_faulthandler.py", line 548, in test_main
    support.run_unittest(FaultHandlerTests)
  File "/home/remi/dev/cpython_test/Lib/test/support.py", line 1328, in run_unittest
    _run_suite(suite)
  File "/home/remi/dev/cpython_test/Lib/test/support.py", line 1303, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_faulthandler.py", line 187, in test_stack_overflow
    other_regex='unable to raise a stack overflow')
  File "Lib/test/test_faulthandler.py", line 105, in check_fatal_error
    self.assertRegex(output, regex)
AssertionError: Regex didn't match: '^Fatal Python error: (?:Segmentation fault|Bus error)\n\nCurrent\\ thread\\ XXX:\n  File "<string>", line 3 in <module>$|unable to raise a stack overflow' not found in ''


Thanks a lot,

Remi.

Info: I read issue 12469 but I prefered to create new issue.

OpenBSD's threads are userland threads, and sigaltstack() doesn't work when the program is built with -pthread:
http://marc.info/?l=openbsd-bugs&m=114323355014696&w=2

Note that POSIX warns about this:
http://www.opengroup.org/onlinepubs/000095399/functions/sigaltstack.html
""""
Use of this function by library threads that are not bound to
kernel-scheduled entities results in undefined behavior.
"""

I think we should skip this test on OpenBSD when Python is compiled with threads support.
Out of curiosity, could you try this:
$ ./python -c "import faulthandler; faulthandler.enable(); faulthandler._stack_overflow()"; echo $?

And if you're motivated, you could try it again after having built python with './configure --without-threads'.

Hi,

results:
>Out of curiosity, could you try this:
>$ ./python -c "import faulthandler; faulthandler.enable(); faulthandler._stack_overflow()"; echo $?

$ ./python -c "import faulthandler; faulthandler.enable(); faulthandler._stack_overflow()"; echo $?
zsh: illegal hardware instruction (core dumped)  ./python -c 
132

>And if you're motivated, you could try it again after having built python with './configure --without-threads'.

It does not build completely, I have a problem if I add --without-threads:
$ make
[...]
./Modules/posixmodule.c:4582: undefined reference to `sched_get_priority_min'
libpython3.3m.a(posixmodule.o)(.text+0x430b): In function `posix_sched_get_priority_max':
./Modules/posixmodule.c:4565: undefined reference to `sched_get_priority_max'
collect2: ld returned 1 exit status
*** Error code 1

It seems that it needs -pthread even if I precise --without-threads. Must I open a new ticket for this problem?

Thanks for your help,

Remi.

> I have a problem if I add --without-threads

Yeah, it's a recent regression: I opened the issue #12871. I don't think that it's specific to OpenBSD.

> Yeah, it's a recent regression: I opened the issue #12871. I don't think that it's specific to OpenBSD.

Thanks.

> It does not build completely, I have a problem if I add
> --without-threads:

Until this gets fixed, if you want to do a quick test, you could just remove the calls to sched_get_priority_(min|max):

"""
diff -r 0968acf0e6db Modules/posixmodule.c
--- a/Modules/posixmodule.c     Wed Aug 31 16:52:12 2011 +0200
+++ b/Modules/posixmodule.c     Wed Aug 31 22:51:13 2011 +0200
@@ -4562,7 +4562,6 @@
 
     if (!PyArg_ParseTuple(args, "i:sched_get_priority_max", &policy))
         return NULL;
-    max = sched_get_priority_max(policy);
     if (max < 0)
         return posix_error();
     return PyLong_FromLong(max);
@@ -4579,7 +4578,6 @@
 
     if (!PyArg_ParseTuple(args, "i:sched_get_priority_min", &policy))
         return NULL;
-    min = sched_get_priority_min(policy);
     if (min < 0)
         return posix_error();
     return PyLong_FromLong(min);
"""

That should allow you to rebuild with 'without-threads'.

Hi,

without-threads, it segfault:

$ ./python -c "import faulthandler; faulthandler.enable(); faulthandler._stack_overflow()"; echo $?
Fatal Python error: Segmentation fault

Current thread 0x0000000000000000:
  File "<string>", line 1 in <module>
zsh: segmentation fault (core dumped)  ./python -c 
139


Thanks,

Remi.

However, if I run test_faulthandler.py, it seems to be ok:

$ ./python Lib/test/test_faulthandler.py
test_disable (__main__.FaultHandlerTests) ... ok
test_dump_traceback (__main__.FaultHandlerTests) ... ok
test_dump_traceback_file (__main__.FaultHandlerTests) ... ok
test_dump_traceback_threads (__main__.FaultHandlerTests) ... skipped 'need threads'
test_dump_traceback_threads_file (__main__.FaultHandlerTests) ... skipped 'need threads'
test_dump_tracebacks_later (__main__.FaultHandlerTests) ... skipped 'need faulthandler.dump_tracebacks_later()'
test_dump_tracebacks_later_cancel (__main__.FaultHandlerTests) ... skipped 'need faulthandler.dump_tracebacks_later()'
test_dump_tracebacks_later_file (__main__.FaultHandlerTests) ... skipped 'need faulthandler.dump_tracebacks_later()'
test_dump_tracebacks_later_repeat (__main__.FaultHandlerTests) ... skipped 'need faulthandler.dump_tracebacks_later()'
test_dump_tracebacks_later_twice (__main__.FaultHandlerTests) ... skipped 'need faulthandler.dump_tracebacks_later()'
test_enable_file (__main__.FaultHandlerTests) ... ok
test_enable_single_thread (__main__.FaultHandlerTests) ... ok
test_fatal_error (__main__.FaultHandlerTests) ... ok
test_gil_released (__main__.FaultHandlerTests) ... ok
test_is_enabled (__main__.FaultHandlerTests) ... ok
test_read_null (__main__.FaultHandlerTests) ... ok
test_register (__main__.FaultHandlerTests) ... ok
test_register_chain (__main__.FaultHandlerTests) ... ok
test_register_file (__main__.FaultHandlerTests) ... ok
test_register_threads (__main__.FaultHandlerTests) ... ok
test_sigabrt (__main__.FaultHandlerTests) ... ok
test_sigbus (__main__.FaultHandlerTests) ... ok
test_sigfpe (__main__.FaultHandlerTests) ... ok
test_sigill (__main__.FaultHandlerTests) ... ok
test_sigsegv (__main__.FaultHandlerTests) ... ok
test_stack_overflow (__main__.FaultHandlerTests) ... ok
test_unregister (__main__.FaultHandlerTests) ... ok

----------------------------------------------------------------------
Ran 27 tests in 1.281s

OK (skipped=7)

Remi.

> without-threads, it segfault:
>

It's normal :-)
_stack_overflow triggers - as it names implies - a stack overflow.
However, as you can see in the output, faulthandler is now able to
catch the SIGSEGV and display the backtrace (because it set up an
alternate stack for the signal handler with sigaltstack).

> However, if I run test_faulthandler.py, it seems to be ok:

Yes: the test checks that the stack overflow was correctly caught by
faulthandler.

@Victor: can I commit the patch?

> @Victor: can I commit the patch?

I don't like the skip message. It doesn't tell that the problem comes 
from sigaltstack() and it doesn't contain the issue number. I would 
expect something like: "Issue #12868: sigaltstack() doesn't work on 
OpenBSD if Python is compiled with pthread".

Do you think that the bug will be fixed in OpenBSD? If yes, we should 
test the OpenBSD version in the skip. But it looks like OpenBSD thread 
implementation is very different than operating systems (e.g. threads 
are run in user space), and I don't expect a new implementation before 
some months/years...

Anyway, skip the test if the right fix for this issue. Python cannot fix 
kernel/libc bugs.

Heya.
OpenBSD does support 1:1 threads via the RThread library
since 2005, thanks to tedu@ and more fantastic guys!
It about to be super-stable (one commit in 2011, last "real
fix" in april 2010).
(There is a techtalk from tedu@ (Ted Unangst) about this library
on YouTube, btw.)

> OpenBSD does support 1:1 threads via the RThread library
> since 2005, thanks to tedu@ and more fantastic guys!
> It about to be super-stable (one commit in 2011, last "real
> fix" in april 2010).
> (There is a techtalk from tedu@ (Ted Unangst) about this library
> on YouTube, btw.)

Does Python support the RThread library? If not, is it planned? Is 
anyone working on it?

In Python 3.3, you can use sys.thread_info to check which threading 
library is used.

> In Python 3.3, you can use sys.thread_info to check which threading 
> library is used.

Great!  I didn't know that!

> Great!  I didn't know that!

It's a new feature of Python 3.3. I added it to skip a test on old FreeBDB, see test_threadsignal.py:
------------------------
USING_PTHREAD_COND = (sys.thread_info.name == 'pthread'
                      and sys.thread_info.lock == 'mutex+cond')
...
    @unittest.skipIf(USING_PTHREAD_COND,
                     'POSIX condition variables cannot be interrupted')
    def test_lock_acquire_interruption(self):
------------------------

It is also used in test_os.py:
---------------
if hasattr(sys, 'thread_info') and sys.thread_info.version:
    USING_LINUXTHREADS = sys.thread_info.version.startswith("linuxthreads")
else:
    USING_LINUXTHREADS = False
---------------

This "linux threads" check does already exist in Python 3.2, but is uses:
---------------
    libpthread = os.confstr("CS_GNU_LIBPTHREAD_VERSION")
    USING_LINUXTHREADS= libpthread.startswith("linuxthreads")
---------------

See also the doc:
http://docs.python.org/dev/library/sys.html#sys.thread_info

Here's a patch with an updated skip message.

As for rthreads support, a quick search seems to indicate that its API is exactly the same as pthreads, and it's even binary compatible. Python will automatically use it when run on a OpenBSD system with rthreads enabled.

> As for rthreads support, a quick search seems to indicate that its API is
> exactly the same as pthreads, and it's even binary compatible. Python will
> automatically use it when run on a OpenBSD system with rthreads enabled.

Well... not exactly. I asked on #openbsd:

22:07 < haypo> hi. what is the status of rthread? it looks like it is not 
available by default
22:14 < tp76> I might be wrong, but I don't think much work has been done on 
that in a while.
22:15 < haypo> tp76: i'm working on Python. Python is linked to pthread. I 
would like to know if we can link Python to rthread
22:16 < farhaven> no, you can't
22:17 < farhaven> rthreads is not (yet) a drop in replacement for pthreads and 
it basically works only if you use 
                  it for kernel threads
22:17 < farhaven> at least the manpage for rfork() advises against using it in 
userspace to create rthreads
22:18 < haypo> farhaven: does rthread have a userland API, similar to pthread, 
to manage threads?
22:18 < farhaven> nope, not that i know of
22:18 < haypo> i cannot find informations about rthread, only some old 
documents (2005)
22:18 < farhaven> afaik the only thing exposed to userland is rfork()'s 
RFTHREAD
22:19 < farhaven> i think tedu made a presentation about rthreads a while ago
22:19 < farhaven> but yeah, i wondered about that too one or two months ago
22:19 < farhaven> and it turned out, rthreads are not exactly usable :D

Your last patch is correct. Go ahead.

New changeset a29b72950795 by Charles-François Natali in branch 'default':
Issue #12868: Skip test_faulthandler.test_stack_overflow() on OpenBSD:
http://hg.python.org/cpython/rev/a29b72950795

Committed.

Rémi, thanks once again for this report!