Can you please provide a minimal runnable example. See http://sscce.org.

like this?

try to change datatype to svg or png. without ylim there are no problems, too. it looks like that this problem only shows with very large negative numbers.

import matplotlib.pyplot as plt


data = [[2,3,1,2,3,10e50], [2.3, 1, -2, -10e34]]

#without y_lim
def box_plot(data, datatype):
    plt.figure("nozoom")
    plt.boxplot(data, labels = ["data1", "data2"], sym="o", meanline=True, notch=False)
    plt.savefig('nofail.'+datatype)
    plt.clf()

box_plot(data, 'pdf')

#with y_lim
def box_plot_ylim(data, ylim, datatype):
    plt.figure("zoom")
    plt.boxplot(data, labels = ["data1", "data2"], sym="o", meanline=True, notch=False)
    plt.ylim(ylim)
    plt.savefig('fail.'+datatype)
    plt.clf()

box_plot_ylim(data, (-5, 5), 'pdf')

I can reproduce the memory error with python 2.7, matplotlib 2.2.2, TkAgg as well as Qt4Agg. I can also reproduce with python 3.6, master, Qt5Agg. Both on Windows8.1.

What's funny is that it works fine for the last data value being set to -1e34 or -100e34, yet it fails for -10e34.

I cannot reproduce this with Python 3.6, MPL v2.2.2 on (Windows subsystem for) Linux

I also cannot reproduce this on vanilla Windows with Python 3.6 and MPL v2.1.2 & v2.2.2 on my admittedly pretty high-end work machine.

I can report however that the test case with the zoomed limits does seem to take much longer to render than it should.

I General we don’t garauntee to filter every bad value out of the input. In this case I can only assume the very large numbers are meant to represent bad data. Suggest masking your arrays before passing to boxplot or any other Matplotlib function is the right way to specify data as bad otherwise you are bound to hit floating point problems somewhere along the line.

@jklymak -1e34 is a perfectly valid value. It should by no means being filtered out, since that would change the boxplot statistics. And using such a value should not result in a memory error.

one thing to check: inspect the artists that represent the whiskers and see how many points are in that path

@ImportanceOfBeingErnest Yes, -1e34 is perfectly valid floating point number, but you can't do valid floating point arithmetic with it unless the other numbers are very large as well.

Do this:

a = np.array([1e10], dtype=np.float64)
b = np.array([5.], dtype=np.float64)
c = a-b
d = c-a
print(d)

you get [ -5.] as the output.

Now do

a = np.array([1e17], dtype=np.float64)
b = np.array([5.], dtype=np.float64)
c = a-b
d = c-a
print(d)

[ 0.]

So yes, -1e34 is a perfectly valid floating point number, but you can't do floating point arithmetic properly unless the other values are on the order of 1e19 and expect to get anything sensible out.

I don't know thats the problem here, but I do know that mixing -5 and -1e34 is asking for trouble, and users shouldn't expect miracles. We can try to work around such issues, or folks can just be cognizant of how floating point arithmetic works and precondition their data in the way that makes sense for their data set.

I don't quite get the point. Surely any maths on those numbers is accurate within the limits of floating point accuracy. Compared to 1e34 it does not actually matter if some result is +5 or -5. But this issue is not about the wrong mean shown on the plot or similar.

Because the error is only triggered when zooming in to -5 to +5...

Ok, agreed, I mean it's just a memory error from a plot with 2 boxes and 10 lines. Can't be that serious after all.

This is super weird. The exception is coming from

btw i have got that error after i changed the order of the boxes. maybe the error is dependent on the positon of the very large negative number (while zoomed in).

I did not dig deep enough,

The problem is that buffersize_int is not updated to match the new buffersize when the buffer is realloc'd, so it's doubled for every extra character over the original buffer size. I'm not sure why we even have buffersize_int in the first place.