Stackless 3.x segfaults on MacOS

[akruis]

I have no Mac. Therefore I can't debug or test on MacOS. I can use Travis CI to compile Stackless 2.7.15 and 3.6.6. Stackless 3.5.6 fails to compile.

Unfortunately Stackless 3.6.6 does not work. Example::

(testenv) dhcpmue-5:stackless-366-export kruis$ PYTHONPATH=$(pwd)/Lib python Stackless/unittests/test_watchdog.py 
testReceiveOnMain (__main__.TestDeadlock)
(soft) Thest that we get a deadock exception if main tries to block ... ok
testReceiveOnMain_H (__main__.TestDeadlock)
(hard) Thest that we get a deadock exception if main tries to block ... ok
test_error_propagation_when_not_deadlock (__main__.TestDeadlock) ... Segmentation fault: 11

[akruis]

This could be related to the problem reported in pull request #163: "In fact it no longer works for gcc 5.4."
I'll replace the trick and then we will know ...

[ctismer]

Hi Anselm, does it make sense for me to try?
I have more than one Mac machine.

[akruis]

@ctismer Hi Christian, your help is more than welcome. Could you try master-slp too?

[akruis]

@ctismer You can use the instructions for Linux https://github.com/stackless-dev/stackless/wiki/BuildForConda#building-on-linux to reproduce the faulty build on your Mac.

I'm fairly sure that the problem is caused by LTO. You could try the following patch:

diff --git a/Stackless/core/slp_transfer.c b/Stackless/core/slp_transfer.c
index 6564efd1f4..270521f499 100644
--- a/Stackless/core/slp_transfer.c
+++ b/Stackless/core/slp_transfer.c
@@ -117,6 +117,7 @@ slp_transfer(PyCStackObject **cstprev, PyCStackObject *cst,
 {
     PyThreadState *ts = PyThreadState_GET();
     int result;
+    static int (*volatile slp_switch_ptr)(void) = slp_switch;
 
     /* since we change the stack we must assure that the protocol was met */
     STACKLESS_ASSERT();
@@ -148,7 +149,7 @@ slp_transfer(PyCStackObject **cstprev, PyCStackObject *cst,
     _cstprev = cstprev;
     _cst = cst;
     _prev = prev;
-    result = slp_switch();
+    result = slp_switch_ptr();
     SLP_ASSERT_FRAME_IN_TRANSFER(ts);
     if (!result) {
         if (_cst) {

With this code, slp_switch() is called via a pointer. The assembly code within slp_switch assumes, that the respective ABI spec applies to slp_switch(), which is not guaranteed in presence of LTO.

[akruis]

I just wrote a small test program

#include <stdio.h>

void function_a(void)
{
  puts("Hello World!");
}

static void function_b(void)
{
  puts("function_b called");
}

static void function_c(void)
{
  puts("function_c called");
}


int main(int argc, char *argv[])
{
  static void (* volatile b_pointer)(void) = function_b;
  static void (* c_pointer)(void) = function_c;

  function_a();
  b_pointer();
  c_pointer();
  return 0;
}

Then I compiled it using clang 6.0.0 and gcc 6.3.0 with -O3 and looked at the generated assembly code:

• clang inlines function_a() and function_c(),
• gcc inlines function_a()
• gcc with -fwhole-program eliminates function_a()

Obviously the only reliable way to guarantee that the function from the same translation unit gets called without optimisations is to use a volatile function pointer. Therefore I'll apply the patch from my previous post.

[Fohlen]

I can report that compiling stackless on OSX 10.14.2 (Mojave) with stable OSX (Apple LLVM version 10.0.0 (clang-1000.10.44.4)) works successfully. Further I can also report that the multiprocessing_fork test fails with

Fatal Python error: Segmentation fault

Current thread 0x00000001074ec5c0 (most recent call first):
  File "/Users/fohlen/workspace/stackless/Lib/multiprocessing/connection.py", line 581 in __init__
Fatal Python error: Segmentation fault

Current thread 0x00000001074ec5c0 (most recent call first):
  File "/Users/fohlen/workspace/stackless/Lib/multiprocessing/connection.py", line 581 in __init__
Warning -- Dangling processes: {<ForkProcess(QueueManager-462, stopped[SIGSEGV])>}
Warning -- Dangling processes: {<ForkProcess(QueueManager-462, stopped[SIGSEGV])>}
test test_multiprocessing_fork failed -- multiple errors occurred; run in verbose mode for details
0:02:51 load avg: 19.21 [410/415/6] test_asyncio passed (62 sec) -- running: test_lib2to3 (57 sec), test_concurrent_futures (107 sec), test_multiprocessing_spawn (94 sec), test_tools (41 sec)
Executing <Handle <TaskWakeupMethWrapper object at 0x105da5be8>(<Future finis...events.py:375>) created at /Users/fohlen/workspace/stackless/Lib/asyncio/selector_events.py:512> took 0.171 seconds
/Users/fohlen/workspace/stackless/Lib/unittest/mock.py:1865: ResourceWarning: unclosed <socket.socket fd=12, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 52569), raddr=('127.0.0.1', 52570)>
  setattr(_type, entry, MagicProxy(entry, self))
/Users/fohlen/workspace/stackless/Lib/asyncio/selector_events.py:663: ResourceWarning: unclosed transport <_SelectorSocketTransport fd=12>
  source=self)
/Users/fohlen/workspace/stackless/Lib/selectors.py:192: ResourceWarning: unclosed <socket.socket fd=12, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 52590), raddr=('127.0.0.1', 52591)>
  raise KeyError("{!r} is not registered".format(fileobj)) from None

Other than this other failed tests seem to be minor naming inconveniences with Python3.

[akruis]

@Fohlen Thank you very much for your feedback. Which version or branch did you compile?

[Fohlen]

@akruis I was building 3629160 (branch master-slp)