I could reproduce this in version 6.4.0 on the same machine that produced the crash in 2018. No graphics driver updates have been applied. The test with 1000 vertices runs within ~10 secs. The test with 5000 vertices crashes octave-gui completely and directly jumps into system debugger. There is no console output.

After opening the debugger I got the following information

> Ausnahmefehler bei 0x000007FEDA14806D (glu32.dll) in octave-gui.exe: 0xC0000005: Zugriffsverletzung beim Lesen an Position 0x0000000059889000

English translation:

> Exception at 0x000007FEDA14806D (glu32.dll) in octave-gui.exe: 0xC0000005: Access violation reading address 0x0000000059889000

The call stack of the main thread may give a rough idea where this came from:

glu32.dll!000007feda14806d()
glu32.dll!000007feda14831c()
glu32.dll!000007feda148701()
glu32.dll!000007feda14659b()
glu32.dll!000007feda143e0b()
liboctinterp-9.dll!000000006ebbe8f3()
liboctinterp-9.dll!000000006ebad04d()
liboctinterp-9.dll!000000006ebc63e4()
liboctinterp-9.dll!000000006ebc6eef()
liboctinterp-9.dll!000000006ebad04d()
liboctinterp-9.dll!000000006ebc2510()
liboctinterp-9.dll!000000006ebc2874()
liboctinterp-9.dll!000000006ebad04d()
liboctgui-6.dll!000000006c0aa9b0()
liboctgui-6.dll!000000006c09892f()
Qt5Widgets.dll!00000000092f3eb5()
Qt5Widgets.dll!00000000092d6f28()
Qt5Widgets.dll!0000000009297983()
Qt5Widgets.dll!00000000092a032e()
liboctgui-6.dll!000000006c150a86()
Qt5Core.dll!000000006691e4f0()
Qt5Widgets.dll!00000000092ceb0b()
Qt5Widgets.dll!00000000092a8bc9()
Qt5Widgets.dll!00000000092a9518()
Qt5Widgets.dll!00000000092d0280()
Qt5Widgets.dll!00000000092d7627()
Qt5Widgets.dll!00000000093de597()
liboctgui-6.dll!000000006c1f5a74()
Qt5Widgets.dll!0000000009297983()
Qt5Widgets.dll!00000000092a032e()
liboctgui-6.dll!000000006c150a86()
Qt5Core.dll!000000006691dbea()
Qt5Core.dll!00000000669244c1()
qwindows.dll!000000006dd4418e()
Qt5Core.dll!00000000669785e3()
qwindows.dll!000000006dd44175()
Qt5Core.dll!000000006691c8c3()
Qt5Core.dll!0000000066925507()
liboctgui-6.dll!000000006c159d58()
octave-gui.exe!0000000000402f47()
octave-gui.exe!00000000004013b4()
octave-gui.exe!000000000040150b()
kernel32.dll!000000007728556d()
ntdll.dll!00000000773e372d()

P.S.: Efficiency is still a topic.

I suggest changing the status of this bug from "Need Info" to "Confirmed".

Is there any reasons not to do so?

The memory consumption for nr_of_vertices ~800 in the OP's example code is only around 100 MB.
So I guess there's some internal OOM error or overflow behind the scenes in the OpenGL code in Octave itself (just a WAG).

As an aside, the code we have in Octave for plotting patches is not very efficient anyway.

The Windows-supplied OpenGL driver is pathetic. Better use the Octave supplied one.

@pantxo: I have renamed octaves opengl.dll and checked with depends.exe that octave is now using Windows opengl.dll.

My test succeeds with 1000 vertices that are drawn a bit slow but correctly at first. But hiding the window and causing a refresh leads to a crash of octave-gui again.
The same behavior shows octave-cli often but not any time.

My system uses Intel HD-Graphics 520 with OpenGL-version 4.4 on Windows 7.

Because I am doing a lot of graphics I frequently create crashes of octave by using certain parameter combinations on plot commands. This may be a wrong color specification, a certain number of vertices or just a certain property. I think there is a lot of work to do to get octave graphics more stable.

On linux with llvmpipe driver it works fine for me.
Print returns after ~19 sec with a warning (which I think is OK).

 tic; print('-dpsc2', sprintf('-f%d',gcf()),sprintf('-r%d',300),'test1.ps'); toc

GL2PS info: OpenGL feedback buffer overflow
warning: gl2ps_renderer::draw: retrying with buffer size: 8.4E+06 B
Elapsed time is 19.231 seconds.

It is quite possible it is one of those race conditions with ghostscript.


Dmitri.
--

On GNU/Linux, the fill command works for me, but the following print command burns CPU time and never returns. It ran for 30 minutes with no output on my system before I canceled it.

This works for me, but I am testing on a Linux platform.  When you say "crashes", do you mean the program segfaults and disappears?  Or does Octave produce an error and return you to the command line?

What happens if you use the CLI version of Octave versus the GUI?

Which toolkit are you using for plotting?

I found this bug while trying to reproduce a failure when exporting postscript files. The problems may therefore be somehow linked.

==Description==

When creating a 2d plot containing a filled patch object with 1000 vertices created with fill() octave crashes immediately.

==Example==

fill([-0.5,1,1.5,0],[0,-0.5,1,1.5],[200,217,238]./255,'edgecolor',[0.7,0.7,0.7],'linewidth',0.5);

Postscript test

If you get the above working, try to export it twice to a postscript file:

print('-dpsc2', sprintf('-f%d',gcf()),sprintf('-r%d',300),'test.ps');
print('-dpsc2', sprintf('-f%d',gcf()),sprintf('-r%d',300),'-append','test.ps');