bugGNU Octave - Bugs: bug #48669, Segfaults at exit after using...


bug #48669: Segfaults at exit after using OpenGL-based toolkits in --no-gui mode

Submitted by:  Dan Sebald <sebald>
Submitted on:  Mon 01 Aug 2016 07:51:25 AM UTC  
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Duplicate Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  GNU/Linux

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)

Fri 10 Nov 2017 06:44:50 AM UTC, comment #21: 

Probably not.  Crashing doesn't come to mind, but I've upgraded my system bundle, so a lot has changed here since then.  Also, there was a recent bug related to Mac OS freezing at exit:


I put a very short patch there which does a wait() on the thread quit() -- the method shown in Qt documentation.  It seems to me that wait is a very critical element regardless of operating system.  Perhaps that was the issue on my system a year ago, which lead to this bug report (my system didn't freeze, instead seg-faulted, but different OS's behave differently in broken scenarios).  You might want to look into that bug and apply the patch.  Pantxo suggested that there might be an alternate way to have the signal itself wait for the thread to finish by changing a property of the signal.  Ultimately, the two approaches are the same thing.  In any case, this bug report (48669) can be closed and marked "out-of-date" or something similar.

Dan Sebald <sebald>
Fri 10 Nov 2017 06:06:06 AM UTC, comment #20: 

@Dan: This bug report is now a year old.  Are you still getting segfaults with Qt?

Rik <rik5>
Project Administrator
Wed 21 Sep 2016 06:04:41 AM UTC, comment #19: 

Still segfaults for both toolkits:

octave:1> graphics_toolkit ('qt')
octave:2> demo waterfall 1
octave:3> exit

panic: Segmentation fault -- stopping myself...
Segmentation fault

I'm probably the one to chase this down since it only seems to be happening with Nvidia cards/drivers.

Dan Sebald <sebald>
Wed 21 Sep 2016 04:00:21 AM UTC, comment #18: 

@Dan: Can you re-test again?  Markus and I recently changed code in the initialization of the OpenGL context.

Rik <rik5>
Project Administrator
Sun 21 Aug 2016 03:30:04 PM UTC, comment #17: 

It appears to be all plots, not just surface.

Dan Sebald <sebald>
Sun 21 Aug 2016 02:42:03 PM UTC, comment #16: 

@Dan: Is it only sombrero, or does any surface object like peaks() also freeze the GUI terminal window?

Rik <rik5>
Project Administrator
Sun 21 Aug 2016 05:28:55 AM UTC, comment #15: 

I pulled and updated to the most recent code.  Yes, FLTK no longer crashes upon plotting.  The plot appears correct.

However, the GUI terminal emulator consistently freezes upon calling "sombrero".  (Can still type commands such as "exit" and they are recognized, the text just doesn't appear in the window.)  In some sense that is better than randomly freezing.  It may not be that the freezing is related to this bug.  OpenGL plotting seems to have developed a strange black-background on resizing which I've described in another bug report.

Dan Sebald <sebald>
Sun 21 Aug 2016 04:45:59 AM UTC, comment #14: 

I pushed the cset from Markus here (http://hg.savannah.gnu.org/hgweb/octave/rev/2aac9ec7df29).  Can you re-test?

Rik <rik5>
Project Administrator
Fri 12 Aug 2016 07:38:42 PM UTC, comment #13: 

Yes.  Markus put a small changeset here:


but I don't think it has been applied yet because FLTK is still crashing on sombrero() in the latest development code.

Dan Sebald <sebald>
Thu 11 Aug 2016 11:03:03 PM UTC, comment #12: 

@Dan: Did you ever get a response about get_maxlights()?  Do we need to do anything there?

Rik <rik5>
Project Administrator
Tue 02 Aug 2016 10:12:59 PM UTC, comment #11: 

As for the seg-fault at exit for both FLTK and Qt, I wonder if there needs to be a glFinish() somewhere before leaving the main application.  glFinish() is like an OpenGL flush that waits until all OpenGL commands currently queued for OpenGL are finished.  Could it be that there is a race condition at exit between the application quitting and Qt/FLTK or some other OpenGL stuff to be processed?  Again, I'm not an OpenGL expert.

Dan Sebald <sebald>
Tue 02 Aug 2016 09:38:21 PM UTC, comment #10: 

OK, I found one bug, and it has to do with what I guessed concerning FLTK, but it isn't the at-exit bug.  I bisected the source and found that the following changeset causes the FLTK draw problems:

changeset:   22192:20b225a3ebf8
date:        Sat Jul 23 17:45:32 2016 +0200
files:       doc/interpreter/genpropdoc.m libinterp/corefcn/gl-render.cc libinte
Update to light (patch #8943)

By my reasoning, if Fl_Gl_Window() of

  OpenGL_fltk (int xx, int yy, int ww, int hh, double num)
    : Fl_Gl_Window (xx, yy, ww, hh, 0), number (num), renderer (),
      in_zoom (false), zoom_box ()

is failing, it must be something in the initialization prior to drawing that is the problem.  So, here is the suspect hunk in that changeset:

 opengl_renderer::opengl_renderer (void)
   : toolkit (), xform (), xmin (), xmax (), ymin (), ymax (),
     zmin (), zmax (), xZ1 (), xZ2 (), marker_id (), filled_marker_id (),
@@ -606,6 +633,9 @@
   if (! ok)
     error ("the size of GLsizei is smaller than the size of int");

+  // Check actual maximum number of lights possible
+  max_lights = get_maxlights ();

   err_disabled_feature ("opengl_renderer", "OpenGL");

That get_maxlights() routine has an "if (glGetError ())" call within.  So, that is an OpenGL call outside of the Fl_Gl_Window instance, which I guess is unpredictable by the FLTK rules.  I commented out the added line above, recompiled and FLTK works again.

I'm going to link to this post at the original bug report and have the changset author see if that initialization can be done after the Fl_Gl_Window is instantiated.

Dan Sebald <sebald>
Tue 02 Aug 2016 05:58:01 PM UTC, comment #9: 

I picked an old version of Octave a couple weeks back at random:

hg update 22154:ff54e7882863

and rebuilt.  Both FLTK and Qt work fine for the Nouveau driver, no crashes...(reboot)...With Nvidia driver, both FLTK and Qt create a correct plot, but use of both toolkits will cause a segmentation fault at exit.

A wild guess, but I'm wondering about the use of OpenGL elsewhere in the Octave program, its initialization and so on.  I see there is this opengl_renderer() class.  For example, I'm guessing that OpenGL_fltk class is using these opengl_renderer routines for drawing the plot.  That is, only an Fl_Gl_Window is supposed to be using OpenGL commands in FLTK (unless one uses the route of gl_visual/gl_start/gl_finish in non-Gl FLTK windows

).  If there is some type of OpenGL initialization done by opengl_renderer() prior to Fl_Gl_Window constructor, could that cause a conflict?  It would be like using OpenGL commands outside of Fl_Gl_Window.  I don't know if that is happening or not as I don't know this opengl_renderer class real well.

Dan Sebald <sebald>
Tue 02 Aug 2016 07:47:07 AM UTC, comment #8: 

Version 1:1.0.10-1ubuntu2

does not crash in either the FLTK initialization case or the Qt at exit case.

However, the FLTK plot looks like renderer screen garbage.  (I'll attach a PNG of both.)  Now, Nouveau is an "experimental" driver in the sense that developers aren't 100% sure about how to control the hardware.  But Qt toolkit works.  I'm not seeing anything else on my system graphics failing (but I did notice a one-time screen flash when I created some plot in gnuplot running on its own that I don't see with the Nvidia driver).

On my system, I see libfltk-gl1.3 1.3.2-4.  I could try version 1.3.3 from scratch.

Dan Sebald <sebald>
Tue 02 Aug 2016 07:06:30 AM UTC, comment #7: 

I haven't tried it yet.  I was just following FLTK crash.  It fails at this line of _init_fltk_.cc:

    canvas = new OpenGL_fltk (0, menu_h, ww, hh, number ());

so it is most likely the call to the base-class constructor:

  OpenGL_fltk (int xx, int yy, int ww, int hh, double num)
    : Fl_Gl_Window (xx, yy, ww, hh, 0), number (num), renderer (),
      in_zoom (false), zoom_box ()

i.e., Fl_Gl_Window() is crashing.  I don't see anything special about setting up OpenGL prior to calling this routine in the FLTK documentation.  Is there any other OpenGL-related code called prior to this?

Dan Sebald <sebald>
Tue 02 Aug 2016 06:44:45 AM UTC, comment #6: 

Do you still have crashes if you switch to the nouveau driver?

What OS are you using?

John W. Eaton <jwe>
Project Administrator
Tue 02 Aug 2016 05:22:28 AM UTC, comment #5: 

No difference; exact same output and crashes.  Here are some entries from my config.log:

configure:19791: WARNING: --without-OSMesa specified.  Functions or features that depend on OSMesa will be disabled.


config_opts=' '\''--without-OSMesa'\'''

I also checked the date of $builddir/src/octave to make sure it was built after the configuration.

You're thinking that this is that OSMesa/Nvidia issue?


I'd forgotten about that, but wasn't that related to printing, not rendering?  Something like OSMesa isn't technically following OpenGL, just makes it seem so?  Or is there something similar regarding Gallium/Nouveau?  Although I wouldn't think so, because that would defeat the purpose of OpenGL standardization.

I'll hunt around a bit for what routine exactly is failing for FLTK.

Dan Sebald <sebald>
Tue 02 Aug 2016 03:15:45 AM UTC, comment #4: 

Try configuring with


You can't mix nvidia and Mesa GL libraries.

John W. Eaton <jwe>
Project Administrator
Tue 02 Aug 2016 01:29:31 AM UTC, comment #3: 

octave:1> graphics_toolkit ('fltk')
octave:2> sombrero ()
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
Segmentation fault

OK, Qt then:

octave:1> graphics_toolkit ('qt')
octave:2> sombrero ()
octave:3> get (gcf (), '__gl_version__')
ans = 3.3.0 NVIDIA 340.96
octave:4> get (gcf (), '__gl_vendor__')
ans = NVIDIA Corporation
octave:5> get (gcf (), '__gl_renderer__')
ans = Quadro FX 4600/PCIe/SSE2
octave:6> exit

panic: Segmentation fault -- stopping myself...
Segmentation fault

Oh hey, pretty neat functions.  So my new OS is using the graphics card for rendering, no wonder rotating plots are so much faster now.

Well, I could try Nouveau or Gallium, but they are a bit of work to build.  Maybe I can try debugging for the Nvidia driver as well with some trial and error.

Dan Sebald <sebald>
Mon 01 Aug 2016 11:32:20 PM UTC, comment #2: 

What does the following tell you?

sombrero ()
get (gcf (), '__gl_version__')
get (gcf (), '__gl_vendor__')
get (gcf (), '__gl_renderer__')

John W. Eaton <jwe>
Project Administrator
Mon 01 Aug 2016 10:32:02 PM UTC, comment #1: 

No segfault for me on exit on rev e43d83253e28.

Can you get a gdb backtrace?

Mike Miller <mtmiller>
Project Administrator
Mon 01 Aug 2016 07:51:25 AM UTC, original submission:  

I've started seeing segfaults at exit after using the Qt and Fltk toolkits. Sometimes the Fltk toolkit will fail outright (changeset: 22193:e35866e6a2e0):

sebald@ ~/octave/gnuplot_bug48664 $ /usr/local/src/octave/octave/build1/run-octave --no-gui --silent
octave:1> graphics_toolkit ('fltk')
octave:2> demo('image',1)
image example 1:
colormap (jet (21));
img = 1 ./ hilb (11);
x = y = -5:5;
subplot (2,2,1);
h = image (x, y, img);
ylabel ("limits = [-5.5, 5.5]");
title ("image (x, y, img)");
subplot (2,2,2);
h = image (-x, y, img);
title ("image (-x, y, img)");
subplot (2,2,3);
h = image (x, -y, img);
title ("image (x, -y, img)");
ylabel ("limits = [-5.5, 5.5]");
subplot (2,2,4);
h = image (-x, -y, img);
title ("image (-x, -y, img)");

panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
Segmentation fault

I've gone back two or three changesets and the segfaults still occur at exit.

Dan Sebald <sebald>


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

Attach Files:


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by sebald (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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-11-11 rik5 StatusConfirmed => Duplicate
        Open/ClosedOpen => Closed
    2016-09-02 rik5 StatusReady For Test => Confirmed
    2016-08-21 rik5 StatusWorks For Me => Ready For Test
    2016-08-02 sebald Attached File- => Added Screenshot from 2016-08-02 02:29:03.png, #38074
        Attached File- => Added Screenshot from 2016-08-02 02:30:53.png, #38075
    2016-08-01 mtmiller StatusNone => Works For Me

    Back to the top

    Powered by Savane 3.5