Skip to content
This repository was archived by the owner on Feb 13, 2025. It is now read-only.
This repository was archived by the owner on Feb 13, 2025. It is now read-only.

Stackless 3.x segfaults on MacOS #173

@akruis

Description

@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

Activity

akruis

akruis commented on Nov 11, 2018

@akruis
Author

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

ctismer commented on Nov 11, 2018

@ctismer
Collaborator

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

added a commit that references this issue on Nov 11, 2018
akruis

akruis commented on Nov 11, 2018

@akruis
Author

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

akruis

akruis commented on Nov 12, 2018

@akruis
Author

@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

akruis commented on Nov 12, 2018

@akruis
Author

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

Fohlen commented on Jan 9, 2019

@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

akruis commented on Jan 12, 2019

@akruis
Author

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

Fohlen

Fohlen commented on Jan 15, 2019

@Fohlen

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

17 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @mikalv@akruis@ctismer@Fohlen

        Issue actions

          Stackless 3.x segfaults on MacOS · Issue #173 · stackless-dev/stackless