Done
|
I suggest changing the status of this bug from "Need Info" to "Confirmed".
Is there any reasons not to do so?
|
Surprisingly the problems do NOT arise when running octave from a windows cygwin-installation! The test with 1000 vertices repeatedly succeeds. I tried to call the test with 5000 vertices not producing a crash:
It has a loooong execution time (20 minutes on i7) and needs a loooot of memory (~2.5 GByte) but it does NOT crash. After building up the memory structures (~8 minutes) one CPU core keeps running with 100% but no output appears. There is also no change in memory usage.
GPU usage statistics for octave process while running the command says:
- Dedicated GPU-Memory: 8.2 MByte
- System GPU-Memory: 79.5 MByte
- Committed GPU-Memory: 105.7 MByte
I think this shows that the problem seems to be located in some windows-only glue code or in some windows specific limitations of opengl.
P.S.:
More efficiency in openGL rendering would be heartly welcome.
|
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.
|
I tried to reproduce the test of Philip Nienhuis and got a limit of exactly 550 vertices using octave-cli with FLTK and octaves opengl.dll.
Using windows opengl.dll the limit is even lower at 491 vertices.
The memory limit seems to be system (hardware?) dependent (I have Intel HD-Graphics 520). Maybe there is a check on hardware limits missing before sending data to opengl?
|
@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.
|
FWIW, on my Win7 64bit box, the dev version (64bit indexing) still works reliably with 750 vertices (instead of the 1000 in the example) (Qt toolkit). With the fltk toolkit the limit lies around 955 vertices.
Renaming opengl32.dll to _opengl32.dll brings the limits down .... With fltk Octave crashes already with 750 vertices (FYI the box has NVidia graphics, it has Nvidia supplied opengl drivers).
With Qt graphics, trying with slowly increasing the number of vertices (after closing the figure each time), each time adding 2 vertices, still works fine until ~784 vertices but restarting Octave and then immediately trying e.g., 775 vertices makes Octave crash.
That tastes like there's some memory limit that gets increased slowly when slowly increasing the nr. of vertices, maybe by garbage collection? Intriguing stuff anyway.
|
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.
--
|
@Georg: The OpenGL library may also play a role. Could you switch to the windows provided opengl32.dll (just move the one that is in the Octave bin directory temporarily out of the path and restart Octave) and see if the crash after "fill" is still present (don't try to print or you'll get an expected failure here)?
|
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.
|
I am using windows 7.
"Crash" means the application disappears without any error message.
Unfortunately it seems not to happen every time. So there might be an external condition causing it. I guess it might have to do with graphics hardware.
Sometimes I can reproduce it after every start of octave sometimes it works nicely 10 times in a row.
I reached the exception over to a debugger and got the following message:
My Translation of this ist:
I am using qt graphics toolkit for plotting.
Octave-cli
Using octave-cli I can create a crash too but with fltk toolkit activated.
|
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?
|
Sorry the wrong example made it into my post... Here comes the right one:
P.S. I am missing the preview button on a new bug post a lot...
|
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==
Postscript test
If you get the above working, try to export it twice to a postscript file:
|