Closed jeroen closed 3 years ago
Can you make test
instead of CMD check
to get a bit more resolution about where the hang is? (& if it's always on the same test)
> test()
Loading clustermq
* Option 'clustermq.scheduler' not set, defaulting to ‘LOCAL’
--- see: https://mschubert.github.io/clustermq/articles/userguide.html#configuration
Testing clustermq
✔ | OK F W S | Context
✔ | 2 | bindings
✔ | 5 | util
✔ | 5 1 | zeromq [0.6 s]
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Skip (test-0-zeromq.r:21:5): node hack works
Reason: has_connectivity(Sys.info()["nodename"]) is not TRUE
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
⠏ | 0 | check_args
Perhaps this is just a side effect of the networking on my M1 server and not related to arm64 🤷♂️
Thank you for the report and clarification. I am very confused about this.
First, I thought that you might have hit some socket polling without incoming message that I missed to time out, but the check_args
tests are pure R with no networking involved.
So maybe a hang on the gc collecting the previous test objects, with the context destroy hanging because the socket was not properly closed?
Can you check if the hang location changes with you change test-0-zeromq.r#L21 to skip("")
unconditionally instead?
In this case, I should move over the remaining testing util to the newer ZeroMQ C++ API.
This has started hanging on CI as well, I think because of an incorrect zmq context termination if the local network connection can not be established.
Should be fixed in develop, please reopen if this is not the case
When I run CMD check on an apple arm64 machine, it hangs at the unit tests:
Where it is indefinitely stalled. The contents of
testthat.Rout
don't tell me much more:Any guess what is going wrong?