1

I have a simple loop to plot some accumulating values in some simulation that takes a long time to compute. I reduced it to following MCVE:

import matplotlib.pyplot as plt
import numpy as np

fig = plt.figure()

counter = 0
yvalues = [0]
for k in range(1000):
    for l in range(10_000_000):
        counter += 1 + np.tanh(counter)
        print(k, l, counter)
    yvalues.append(counter)
    plt.plot(yvalues)
    plt.draw()
    fig.canvas.flush_events()

The problem is that after a while I get a notification that "PyCharm is not responding", even though the program is still running and working perfectly well.

The message alone is not the problem yet, but if you just ignore this warning and do not press Wait the program will stop and display

Process finished with exit code 137 (interrupted by signal 9: SIGKILL)

(The same thing happens when you just press Force Quit.)

Does anyone know why this is happening and how to avoid it?

It makes it impossible to run this simulation e.g. overnight as you constantly have to look out for this warning and press Wait again.

flawr
  • 10,814
  • 3
  • 41
  • 71
  • https://stackoverflow.com/questions/30732683/python-sigkill-catching-strategies – Carlos Gonzalez Mar 01 '19 at 11:09
  • @CarlosGonzalez thanks for the link! Actually I'd like to avoid getting a *SIGKILL* in the first place - I just don't know why I am getting it and what I could do to avoid it. (I have the impression that it might have something to do with the `matplotlib`-plot, but I have no idea what exactly is the issue.) – flawr Mar 01 '19 at 11:17
  • That this issue also appear when you run it in the terminal and not in PyCharm? – Carlos Gonzalez Mar 01 '19 at 11:20
  • I just tried that and the plot window doesn't even show up. It does show up however if we append a `plt.pause(0.01)` after, but then we get a similar message *matplotlib is not responding*. – flawr Mar 01 '19 at 11:27

1 Answers1

1

As stated in the linked question in @CarlosGonzalez's comment, SIGKILL may be sent by the Linux OOM (out-of-memory) killer. If this is the case, then the only solution is to use less memory, or obtain more memory.

Given how long it takes to run your MCVE, I am unable to determine the exact source that is using so much memory, but I can guess that it is unrelated to the counter or yvalues --- counter is at most on the order of magnitude 10^10 (1000 * 10_000_000), which fits in a 64-bit integer fine (8 bytes of memory), and yvalues can hold 1000 of those fine too (using 8kB if we suppose it's an array and counter is a 64-bit int).

With the following code, I note that fig.canvas.flush_events() runs rather slowly compared to the rest of the code (try commenting it out and comparing the speed, and note how Ctrl-C/SIGINT fails to stop it):

import matplotlib.pyplot as plt

fig = plt.figure()
counter = 0
yvalues = [0]
for k in range(1000):
    counter += 1e7
    yvalues.append(counter)
    plt.plot(yvalues)
    plt.draw()
    print(k)
    fig.canvas.flush_events()  # Potentially problematic?

Perhaps you might need to reconsider your need to flush the canvas events.

ForgottenUmbrella
  • 1,052
  • 14
  • 14