Zsh kills Python process with plenty of available VM

Question

Level 1

4 points

Zsh kills Python process with plenty of available VM

On a MacBook Pro, 16GB of RAM, 500 GB SSD, OS Sequoia 15.7.1, M3 chip, I am running some python3 code that requires lots of RAM and sure enough, once physical memory is exhausted, swapfiles of about 1GB each start being created, which I can see in /System/Volumes/VM. This folder has about 470 GB of available space at the start of the process (I can see this through get info) however, once about 40 or so swapfiles are created, for a total of about 40GB of virtual memory occupied (and thus still plenty of available space in VM), zsh kills the python process responsible for the RAM usage (notably, it does not kill another python process using only about 100 MB of RAM). What's going on here? All the documentation I was able to consult says macOS is designed to use all available storage on the startup disk (which must be the one I am using since I have only one disk and the available space aforementioned reflects this).

Then why zsh kills the process with so much available VM? Also, I changed the shell from zsh to bash, not sure whether this makes a difference (though it is still zsh that kills the process, not bash). One last note, I do not have administrator rights on this device, so I could not run dmesg to retrieve more precise information, but I doubt my employer put a cap on RAM usage on my profile, since this should not be possible on macOS and even if it were, I suppose it would show when I get info when I check the available space in VM.

Thanks for any insight you can share on this issue, is it a known bug or something? I could not find anything recent on it.

MacBook Pro 13″

Posted on Dec 6, 2025 6:47 AM

Reply

Answer 1

etresoft

Level 9

56,314 points

Dec 9, 2025 8:19 AM in response to gggg87

gggg87 wrote:

I run the following python script in a the same conda environment to see if conda is at fault here>

...

this gets killed by zsh once about 9GB of VM are occupied. I think this is a pretty strong lead on conda being the problem

Conda is only relevant in terms of complicating your setup. You claimed to be trying to start the script without zsh, yet you are still getting messages via zsh. That suggests that your attempts to change your shell from zsh to something else are being thwarted by Conda.

The specific shell being used is irrelevant. If Conda is causing a problem, it might be because, in addition to running a different shell, Conda might also be running an entirely different version of the script than what you expect. This could simply be a bug that was fixed 4 months ago, but Conda is still running the old buggy version.

It is the operating system kernel that is killing the process. zsh is not involved other than being the messenger of bad news.

Reply

Answer 2

etresoft

Level 9

56,314 points

Dec 9, 2025 5:24 PM in response to gggg87

gggg87 wrote:

I think this is a pretty strong lead on conda being the problem here (or python itself perhaps?) but not gurobipy.

Neither conda nor python are responsible for the process being killed. It's using too much RAM and the kernel is killing it.

I don't know the details of how the memorystatus architecture works. It's a big issue on iOS because RAM is so limited. And since macOS is just a "flavour" of iOS, it exists there too, albeit with different parameters.

You might want to try asking your question in the Apple Developer forums. There are actual Apple developer support engineers who might know the details of how memorystatus works on macOS, possibly even how you could disable it or work around it. To be honest, they're usually surprisingly accommodating to people asking funky questions like this. I guess it's a nice break from all the scammers who are complaining about getting their apps rejected.

Reply

Answer 3

gggg87 Author

Level 1

4 points

Dec 10, 2025 5:28 AM in response to Luis Sequeira1

I agree with you that the issue must lie in the conda environment. And thanks a lot for checking that other languages work better. So I will try with an environment created with venv instead, bypassing conda, just as in my Linux machine. conda makes installing gurobipy very straightforward with certain licenses, it also has a very nice IDE, that is why I was using it, but it is quite clear that the price to pay is not worth it in my case. The theory is that a conda environment should not interfere with how the OS works, and only the IDE curbs memory usage at 6GB, but from terminal it should work as if it is not even there. But it is clear that in practice things are different. Luckily a slightly more convoluted licensing can be used with gurobi and just python and I will try that now.

Regarding the shell, somehow I think changing the shell in the terminal settings does not really change the shell as an environment variable. While the terminal settings clearly show in the shell folder /bin/bash, if I echo $SHELL I get zsh, and every time I open a new terminal page I get a warning that the standard shell is zsh and how I can change back to that. So somewhere zsh is still the default and that's perhaps why kernel messages come through zsh still, even though the syntax I use to, say, open GUI applications etc, is the bash one (I hate having to go through the all zsh wrapping with open and -a etc to just do something as simple as "gedit file_name").

Regarding activity monitor, that never get stuck for me of course, since the job gets killed way before vm reaches critical values. It just shows high pressure (yellow, but never red, other than a thin red edge on top of the yellow area).

Finally, a question: you say your memory usage went up to 130GB, what was the total still available in the VM volume? Was it little (I would expect the OS leaves some extra space to spare for good functioning of an ssd, but I would expect that to be, say, no more than a quarter of the total capacity only)?

Reply

Answer 4

Dec 10, 2025 7:28 AM in response to gggg87

gggg87 wrote:

I agree with you that the issue must lie in the conda environment. And thanks a lot for checking that other languages work better. So I will try with an environment created with venv instead, bypassing conda, just as in my Linux machine. conda makes installing gurobipy very straightforward with certain licenses, it also has a very nice IDE, that is why I was using it, but it is quite clear that the price to pay is not worth it in my case. The theory is that a conda environment should not interfere with how the OS works, and only the IDE curbs memory usage at 6GB, but from terminal it should work as if it is not even there. But it is clear that in practice things are different. Luckily a slightly more convoluted licensing can be used with gurobi and just python and I will try that now.

The more you post about that app, the worse it appears; the closer to a research project or one-off or prototype.

Regarding the shell, somehow I think changing the shell in the terminal settings does not really change the shell as an environment variable. While the terminal settings clearly show in the shell folder /bin/bash, if I echo $SHELL I get zsh, and every time I open a new terminal page I get a warning that the standard shell is zsh and how I can change back to that. So somewhere zsh is still the default and that's perhaps why kernel messages come through zsh still, even though the syntax I use to, say, open GUI applications etc, is the bash one (I hate having to go through the all zsh wrapping with open and -a etc to just do something as simple as "gedit file_name").

This message?

The default interactive shell is now zsh.

To update your account to use zsh, please run chsh -s /bin/zsh.

For more details, please visit Use zsh as the default shell on your Mac - Apple Support.

The message is telling you your login shell is bash, not zsh, and that the bash shell is old and deprecated. The linked article has details in how to change the default, as well as how to suppress the deprecation warning ifmyou want to keep the very old version of bash as the default.

Finally, a question: you say your memory usage went up to 130GB, what was the total still available in the VM volume? Was it little (I would expect the OS leaves some extra space to spare for good functioning of an ssd, but I would expect that to be, say, no more than a quarter of the total capacity only)?

Usual free percentage recommendations is probably most of ten percent free on a smaller SSD, and five percent or so on a larger. Running close to the capacity is not the greatest idea with an SSD, too.

Reply