Change:
For a while now, some routines have been segfaulting on darwin. This has become more problematic recently because newer versions of make a call to , which pretty robustly segfaults on darwin. Packages that use in their tests are failing as a result. e.g. 's own tests are of course disabled because they have proven to be so problematic. We've opened some upstream issues for these problems (, ), but I'm increasingly starting to feel these are Our Bugs. The next step is probably to do some proper debugging on these segfaults, but I personally lack the motivation to learn darwin's weird debugging ecosystem (give me gdb and ELF anyday), so instead I'm documenting my findings here. Steps to reproduce the behavior: on darwin (tested x86_64, macos 10.15) When I use a pip-installed version on the same machine it succeeds: Maintainer information:
I can’t reproduce on aarch64-darwin running macOS 12.0.1. I tried both the aarch64 and x86_64 builds of Python. (Not saying this isn’t a problem, but it may be that it’s dependent on the macOS version being run.)
~That is an interesting data point, because I'm quite certain that our uses a much newer SDK version.~ Hold on, I think we've miscommunicated, the pip method works for me too - I suppose listing it as the expected behaviour is unclear. Let me reword.
Does the first of my two snippets fail on your system?
Sorry, yeah. I also tested that first but only posted the second results. Here’s what I get with the first snippet.
I just tested the x86_64-darwin binaries on my aarch64-darwin system and got the crash.
Ok so it is still potentially SDK-version-related.
This sounds very similar to the problem in . I wonder if it's related.
I had a look at this when it was mentioned on matrix. From what I can tell the crash occurs as soon as psutil tries to interact with CoreFoundation types returned from querying the system. I did some printf style debugging by adding calls to , and all I could get was a crash. I suspect it's related to mixing and matching system CoreFoundation with swift-corefoundation built from source. I haven't gotten to the bottom of the issue yet, but if psutil is explicitly linked with system CoreFoundation[1], then it seems to work. that forces the the linker to use system corefoundation. <details<summarycomparison</summaryWithout: With </details
how to resolve the issue?
Not sure if related I am getting this error
I also got same error on our CI (linux armd64) with . Is there a workaround for this?
Closing because of which is supposed to address this. And I can't reproduce on x86_64-darwin.

Discussion:
{ lib, stdenv, buildPythonPackage, fetchPypi, isPy27, python <del> , IOKit </del> <ins> , CoreFoundation, IOKit </ins> , pytestCheckHook , mock , unittest2

"cpu_freq" ]; <del> buildInputs = lib.optionals stdenv.isDarwin [ IOKit ]; </del> <ins> buildInputs = # workaround for https://github.com/NixOS/nixpkgs/issues/146760 lib.optionals (stdenv.isDarwin && stdenv.isx86_64) [ CoreFoundation ] ++ lib.optionals stdenv.isDarwin [ IOKit ]; </ins> pythonImportsCheck = [ "psutil" ];

psd-tools = callPackage ../development/python-modules/psd-tools { }; psutil = callPackage ../development/python-modules/psutil { <del> inherit (pkgs.darwin.apple_sdk.frameworks) IOKit; </del> <ins> inherit (pkgs.darwin.apple_sdk.frameworks) CoreFoundation IOKit; </ins> }; psutil-home-assistant = callPackage ../development/python-modules/psutil-home-assistant { };