bugGNU Octave - Bugs: bug #54762, Using fill with 1000 vertices...

 
 

bug #54762: Using fill with 1000 vertices crashes octave

Submitted by:  Georg Wiora <gwiora>
Submitted on:  Mon 01 Oct 2018 03:21:41 PM UTC  
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Need Info Assigned to:  None
Originator Name:  gwiora Open/Closed:  Open
Release:  4.4.1 Operating System:  Microsoft Windows

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Thu 04 Oct 2018 07:26:27 AM UTC, comment #11:

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.

Georg Wiora <gwiora>
Tue 02 Oct 2018 05:39:36 PM UTC, comment #10:

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.

Philip Nienhuis <philipnienhuis>
Project Member
Tue 02 Oct 2018 07:55:55 AM UTC, comment #9:

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?

Georg Wiora <gwiora>
Tue 02 Oct 2018 07:23:43 AM UTC, comment #8:

@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.

Georg Wiora <gwiora>
Mon 01 Oct 2018 09:30:01 PM UTC, comment #7:

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.

Philip Nienhuis <philipnienhuis>
Project Member
Mon 01 Oct 2018 04:50:55 PM UTC, comment #6:

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.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 01 Oct 2018 04:41:00 PM UTC, comment #5:

@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)?

Pantxo Diribarne <pantxo>
Project Member
Mon 01 Oct 2018 04:20:27 PM UTC, comment #4:

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.

Mike Miller <mtmiller>
Project Administrator
Mon 01 Oct 2018 04:05:27 PM UTC, comment #3:

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.

Georg Wiora <gwiora>
Mon 01 Oct 2018 03:39:21 PM UTC, comment #2:

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?

Rik <rik5>
Project Administrator
Mon 01 Oct 2018 03:27:59 PM UTC, comment #1:

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...

Georg Wiora <gwiora>
Mon 01 Oct 2018 03:21:41 PM UTC, original submission:

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:

Georg Wiora <gwiora>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by gwiora (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-10-01 pantxo CategoryPlotting => Plotting with OpenGL
    2018-10-01 rik5 StatusNone => Need Info

    Back to the top


    Powered by Savane 3.3