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

 
 

bug #54762: Using fill with 1000 vertices crashes octave

Submitter:  Georg Wiora <gwiora>
Submitted:  Mon 01 Oct 2018 03:21:41 PM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Confirmed Assigned to:  None
Originator Name:  gwiora Open/Closed:  * Open
Release:  * 6.3.0 Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 10 Nov 2021 10:09:41 AM UTC, comment #15: 

Works for me with Octave 6.4.0.

Markus Mützel <mmuetzel>
Group administrator
Wed 10 Nov 2021 08:22:10 AM UTC, comment #14: 

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.


Georg Wiora <gwiora>
Fri 16 Nov 2018 01:51:39 PM UTC, comment #13: 

Done

Pantxo Diribarne <pantxo>
Group Member
Fri 16 Nov 2018 01:40:26 PM UTC, comment #12: 

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

Is there any reasons not to do so?

Georg Wiora <gwiora>
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:

fill(rand(5000,1),rand(5000,1),[200,217,238]./255,'edgecolor',[0.7,0.7,0.7],'linewidth',0.5);


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>
Group 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>
Group 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>
Group 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>
Group Member
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:


Ausnahmefehler bei 0x000007FEED89806D (glu32.dll) in octave-gui.exe: 0xC000041D: Unbehandelte Ausnahme während eines Benutzerrückrufs


My Translation of this ist:

Exception at 0x000007FEED89806D (glu32.dll) in octave-gui.exe: 0xC000041D: Unhandled Exception during user callback



I am using qt graphics toolkit for plotting.

Octave-cli

Using octave-cli I can create a crash too but with fltk toolkit activated.


octave:1> fill(rand(1000,1),rand(1000,1),[200,217,238]./255,'edgecolor',[0.7,0.7,0.7],'linewidth',0.5);
fatal: caught signal Segmentation fault -- stopping myself...



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>
Group 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:


fill(rand(1000,1),rand(1000,1),[200,217,238]./255,'edgecolor',[0.7,0.7,0.7],'linewidth',0.5);


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


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');


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 mmuetzel (Posted a comment)
  • -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)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-11-10 mmuetzel Release4.4.1 6.3.0
    2018-11-16 pantxo StatusNeed Info Confirmed
    2018-10-01 pantxo CategoryPlotting Plotting with OpenGL
    2018-10-01 rik5 StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code