Process finished with exit code 137 in PyCharm

Question

When I stop the script manually in PyCharm, process finished with exit code 137. But I didn't stop the script. Still got the exit code 137. What's the problem?

Python version is 3.6, process finished when running xgboost.train() method.

Selfsacrifice

I found that CPU load is rather high when running the script. – Selfsacrifice

How about the memory use? Exit code 137 means your process was killed by SIGKILL (signal 9). Which could happen for a lot of reasons, but usually by excessive memory use. – Myth

@Pang Sorry for confusion. It's the script that finished due to excessive memory use. – Selfsacrifice

It seems that the script ran out of RAM. After optimising the script, it works. Thank you very much.@Myth – Selfsacrifice

Maybe this helps: https://mcmap.net/q/156090/-what-does-39-killed-39-mean-when-processing-a-huge-csv-with-python-which-suddenly-stops – Donnie

@Selfsacrifice can you please tell us what change did u do to resolve this issue ? – Capacity

@Selfsacrifice Please share your solution. – Kobold

Check all your env variables are in place and have a value. See here. – Commissariat

Answer 1

Exit code 137 means that your process was killed by (signal 9) SIGKILL . In the case you manually stopped it - there's your answer.

If you didn't manually stop the script and still got this error code, then the script was killed by your OS. In most of the cases, it is caused by excessive memory usage.

Aguiar

Answer 2

{In my experience}

this is because of Memory issue. When I try to train ml model using sklearn fit with full data set , it abruptly breaks and gives whereas with small data it works fine.

Process finished with exit code 137 (interrupted by signal 9: SIGKILL) Interestingly this is not caught in Exception block either

Hydroplane

It isn't caught because it isn't a python exception. – Blondie

How to solve it then? – Sahib

Unlike other POSIX signals, SIGKILL is not actually signalled to the process and as such it can't possibly be handled by the program code, no matter what programming language or framework you use. So Python is not to blame here. SIGKILL is handled by the kernel itself. It will simply stop process execution and eventually remove it from the process table. You need to look for the source of the KILL signal - who send it and why. May need to search some logs... – Legator

Answer 3

If you are in Ubuntu, increase the SWAP memory. It will work. Use htop to see SWAP usage, when it is full, it will give error 137.

Touzle

welcome to stackoverflow. your answer is useful. Thank you for contributing. A couple of things that can improve your answer would be: adding links to an htop manual and page that explains how to increase SWAP memory, OR explaining these things yourself here. Either way, thank you for your contribution. I'm upvoting it. – Houseroom

Answer 4

In my case, my RAM ran out, whether it is real or virtual.

Split your data into small pieces or expand your virtual memory.

I choose the latter.

Following scipts works on my ubuntu 20.04 TLS.

# disable the use of swap
sudo swapoff -a

# create the SWAP file. Make sure you have enough space on the hard disk.
# here is my size, the total size is bs*count B
sudo dd if=/dev/zero of=/swapfile bs=1024 count=136314880 status=progress
# output:
# 139458259968 bytes (139 GB, 130 GiB) copied, 472 s, 295 MB/s
# 136314880+0 records in
# 136314880+0 records out
# 139586437120 bytes (140 GB, 130 GiB) copied, 472.372 s, 296 MB/s

# Mark the file as SWAP space:
sudo mkswap /swapfile
# output:
# Setting up swapspace version 1, size = 130 GiB (139586433024 bytes)
# no label, UUID=25a565d9-d19c-4913-87a5-f02750ab625d

# enable the SWAP.
sudo swapon /swapfile

# check if SWAP is created
sudo swapon --show
# output:
# NAME      TYPE SIZE USED PRIO
# /swapfile file 130G   0B   -2

# Once everything is set, you must set the SWAP file as permanent, else you will lose the SWAP after reboot. Run this command:
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

After you run your process, memory will grow.

Here is mine:

Good Luck!

reference 1，reference 2

Pastrami

The last step of updating /etc/fstab is not necessary if you only increase the size of an existing swap file, since /swapfile is already in /etc/fstab. – Loma

Answer 5

I had the same error. In my case was related to excessive memory usage. Solved after reseting/cleaning my cache data adding the following code for every variable that will not be used anymore :

MyVariableName = None

Fancy

Could you please elaborate? Do you mean one should insert a literal line of code like "MyValue = None"? – Payload

I re-edited my answer. I added "name of your variable"=None for every variable that I will not use anymore. This resets your variable and free the cache. – Fancy

You should probably use del myVariableName to clear the variable. This makes it no longer in scope and causes it get garbage collected. – Shovelboard

Answer 6

It's not always a memory issue. In my case subprocess.Popen was utilized and it was throwing the error as 137 which looks like signalKILL and the cause is definitely not the memory utilization, because during the runtime it was hardly using 1% of memory use. This seems to be a permission issue after more investigation. I simply moved the scripts from /home/ubuntu to the root directory.

Palmira

Answer 7

I've recently run into this error installing PyCharm on an M1 Mac Mini. It was accompanied by an error that said my SDK was invalid upon compilation of a project. It turns out this was due to my Python Interpreter being pointed at a strange directory, I'm not 100% how this happened.

I went to Preferences > Project:yourProject > Python Interpreter and selected a valid SDK from the drop-down (in my case Python 3.8). You'll know the package is valid because it will populate the package list below with packages.

Again, not sure how it happened on install, but this solved it.

Presentment

Answer 8

There's some relevant answers linked here although they could be more complete. For a more in-depth dive of OOM and badness please see @adam-jaskiewicz's answer at the link above.

Firstly, another user may have killed your program. If you're a power user then this is a permissions and administrative issue. Otherwise talk to your IT manager.

Secondly, another user-space program such as antivirus, watchdog, or even malicious program could have killed your program. On a Linux platform that'd be pretty unlikely as it's less common to run antivirus software, but you'd likely want to whitelist your program, kill/remove the overly aggressive program, or modify your program to evade being detected.

Thirdly, and by far the most likely, the operating system killed your program in which case read on:

The likely issue is that your computer is running out of memory and to prevent resource starvation, the kernel is sending SIGKILL to to terminate your program to free up space.

By far the best solution is to alter your program so that it uses less memory. Some high-reward techniques for this are:

1. Utilize a divide and conquer approach to schedule smaller batches.
2. Choose an algorithm that relies more on computation rather than memory (per operation).
3. Attempt to modify collections in place.
4. Restructure your code such that variables are released more frequently and code is evaluated lazily when possible.
5. Use generators instead of iterators when possible (e.g. if something is only going to be used once or you're running out of memory as in this case).
6. Consider data types that may be require less memory hungry - not everything needs to be a list.
7. Write modules for the most memory intensive parts in a lower level, more time consuming, but also more optimize-able language like C or assembly.

Other band-aid alternatives that I wouldn't recommend if you're already using a modern computer with a relatively ubiquitous operating system are:

• Use psutil to increase the priority of your program (from -20 to 20 [high to low] - allowed defaults per user in /etc/security/limits.conf).
• Have fewer programs running.
• Install more RAM to physically have more memory.
• Downgrade to less resource intensive OS.
• Increase the swap partition to simulate more memory (this is likely going to be excruciatingly slow and wear out your hard drive/SSD over time for no good reason as well as reduce the allocated non-volatile storage).

If you're running a Linux based OS, I ran the following on the command line to verify that my issue was also caused by OOM (note: some people had the errors in different log files such as /var/log/messages, /var/log/kern.log, /var/log/dmesg, etc).

Here's the relevant output for me:

> sudo cat /var/log/syslog | grep kill
Feb 19 00:22:08 <my_hostname> systemd[1756]: app-gnome-pycharm-3002.scope: A process of this unit has been killed by the OOM killer

Grose

Checking /var/log/kern.log is helpful to me. Thanks for providing this answer. – Schipperke

Answer 9

My python process get killed with the 137 error code because my Docker for Windows memory limit was set too low.

Helfand

Answer 10

1. If anyone else were installing pycharm on mac and got the code 137 in PyCharm error while doing a simple print('test') command it most certainly is because of the path to interpreter being present in the new project created.
2. The error I believe is because of python being installed through brew and it not showing up in the "Python X.YZ /Library/Frameworks/Python.framework/Versions/X.YZ/bin/pythonX" path
3. Work around uninstall installed python version using brew and then manually install it.
4. Now it would appear under the interpreter path which is under "Preferences-> Project -> Python Interpreter -> Gear symbol -> add base interpreter" point this to under /Library/Frameworks/.... path

Unquote

Answer 11

From my experience (Python 3.9.13, MacOSX 12.4), the "SIGKILL" behavior can happen as well if the python code causes low memory. If you run the same code from the command line

$>python your_module.py

the code will crash as well.

I work with quite large Pandas DataFrames (millions of rows, some dozen columns). I have a MacMini with 8 GB RAM and observed that the SIGKILL appears if the memory consumed by Python (MacOS activity monitor) exceeds about 60 GB.

Ninebark

Answer 12

This is an OOM (Out-Of-Memory):

The sigkill comes from the Kernel because it's out of free memory.

• buy more RAM
• use an iterative approach to process data in smaller chunks, which fits into RAM
• run your program once without PyCharm (PyCharm requires 1 GiB of RAM or more)
• incrase swap, but you're warned, it's deadly slow
• created virtual memory

Swaim

Answer 13

1. Click on the gear icon.
2. Then set the Poetry environment to Python 3.x.
3. Click Ok and Apply.

Now the code can run without showing any error!

Immigrate