You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 13, 2025. It is now read-only.
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
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 ...
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.
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.
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.
Activity
akruis commentedon Nov 11, 2018
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 commentedon Nov 11, 2018
Hi Anselm, does it make sense for me to try?
I have more than one Mac machine.
Update build.sh: run "make teststackless"
akruis commentedon Nov 11, 2018
@ctismer Hi Christian, your help is more than welcome. Could you try master-slp too?
akruis commentedon Nov 12, 2018
@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:
With this code,
slp_switch()
is called via a pointer. The assembly code within slp_switch assumes, that the respective ABI spec applies toslp_switch()
, which is not guaranteed in presence of LTO.akruis commentedon Nov 12, 2018
I just wrote a small test program
Then I compiled it using clang 6.0.0 and gcc 6.3.0 with -O3 and looked at the generated assembly code:
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 commentedon Jan 9, 2019
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 withOther than this other failed tests seem to be minor naming inconveniences with Python3.
akruis commentedon Jan 12, 2019
@Fohlen Thank you very much for your feedback. Which version or branch did you compile?
Fohlen commentedon Jan 15, 2019
@akruis I was building 3629160 (branch
master-slp
)17 remaining items