FLTK logo

STR #2972

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]

STR #2972

Application:FLTK Library
Status:1 - Closed w/Resolution
Priority:4 - High, e.g. key functionality not working
Scope:1 - Specific to a machine/printer
Subsystem:OpenGL
Summary:segfault from using octave
Version:1.3.2
Created By:muhali
Assigned To:AlbrechtS
Fix Version:None
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:


Name/Time/Date Filename/Size  
 
#1 muhali
07:58 Aug 13, 2013
dbg.txt
17k
 
     

Trouble Report Comments:


Name/Time/Date Text  
 
#1 muhali
10:21 Aug 08, 2013
I get a segfault when running octave (the Matlab clone) on a Debian system (2.6.32-5-amd64), and I think it is caused by fltk. It was compiled using gcc (Debian 4.4.5-8) 4.4.5, and the debug info looks as follows:

octave-cli:1> sombrero
Insufficient GL support
Insufficient GL support

Program received signal SIGSEGV, Segmentation fault.
0x00007fffecf566cc in fl_create_gl_context (g=0x0) at Fl_Gl_Choice.H:102
102   return fl_create_gl_context(g->vis);
Current language:  auto
The current source language is "auto; currently c++".
(gdb) where
#0  0x00007fffecf566cc in fl_create_gl_context (g=0x0) at Fl_Gl_Choice.H:102
#1  0x00007fffecf56a98 in Fl_Gl_Window::make_current (this=0xd66da0) at Fl_Gl_Window.cxx:170
#2  0x00007fffecf45eed in plot_window::show_canvas() () from /usr/local/octave/lib/octave/3.7.5/oct/x86_64-unknown-linux-gnu/__init_fltk__.oc
t
#3  0x00007fffecf4b61f in figure_manager::do_update_canvas(int, graphics_handle const&) () from /usr/local/octave/lib/octave/3.7.5/oct/x86_64-unknown-linux-gnu/__init_fltk__.oc
t
#4  0x00007fffecf4acca in figure_manager::update_canvas(graphics_handle const&, graphics_handle const&) () from /usr/local/octave/lib/octave/3.7.5/oct/x86_64-unknown-linux-gnu/__init_fltk__.oc
t
#5  0x00007fffecf4c954 in fltk_graphics_toolkit::update(graphics_object const&, int) () from /usr/local/octave/lib/octave/3.7.5/oct/x86_64-unknown-linux-gnu/__init_fltk__.oc
t
 
 
#2 greg.ercolano
15:07 Aug 08, 2013
What version of octave?

Also, have you bounced this off the octave folks first?

It seems odd to me that in response to 'where' there is no main()
in the calling stack.. it's as if fl_create_gl_context() is being
called by Fl_Gl_Choice.H with no context at all.

Certainly g->vis being 0x0 is the cause of the crash, the question
seems to be why is it NULL, and what in octave is calling it.
The "Insufficient GL support" is perhaps part of the reason,
though indeed it shouldn't crash (unless the calling application
missed an opportunity to verify GL features it needs are not available)
 
 
#3 muhali
02:51 Aug 09, 2013
to answer your questions:

- octave version: current development tip

- This is an unresolved octave bug (http://savannah.gnu.org/bugs/?31882&)

- "main" is missing because I just included the upper portion of the debug output

More context is in the octave bug report.
 
 
#4 greg.ercolano
21:05 Aug 11, 2013
>> http://savannah.gnu.org/bugs/?31882&

Hmm, when I click that link I get:

    "Error: No group chosen: nogroup"

However, I was able to go to that site and search for that bug number in octave, and came up with this:
http://savannah.gnu.org/bugs/?func=detailitem&item_id=31882

Valgrind output is shown, not gdb, and there's no main() there either.

Would be good if you can post the complete unredacted output of gdb's
'where' command that includes main(), so I can at least trace the stack
through octave's code. It helps to have debugging enabled for the build.

Have to say: octave's code is huge and vast.
Although I did get it to compile, and had to install several other libs before it would build, it wouldn't let me run the "sombrero" command. Just about every command except math operations gave me an "undefined command" error.

Let me ask you this: on this machine that throws the insufficient GL error, try running one of the FLTK opengl demos, such as 'test/cube'. Does it work OK? (I'm assuming you built FLTK from scratch)

Assuming its a bug in FLTK, it would be best if you can replicate the crash in a small C++ opengl program, such as one of the demos. That would at least rule out all of octave, which would be great because it's so large.

Also: This /seems/ like it might be graphics card specific, due to the 'insufficient GL' message. Can you give details about what might be causing that? (ie. what kind of graphics card? what kind of opengl features is octave trying to use that might be causing this? Should it work at all even if it didn't crash, or is octave asking for an opengl feature that perhaps can't be provided by the hardware, and if so, is it checking to see if these features are supported, or is it just assuming they are, and tells fltk to open the window, causing the crash?)
 
 
#5 muhali
03:21 Aug 13, 2013
>> http://savannah.gnu.org/bugs/?31882&

that ampersand was wrong. Sorry.

What I don't understand is that the segfault occurs only when I log in from my home machine. When I log in from another office machine, with a faster connection, everything works.

I'll try to post the full debug info when I'm at home.
 
 
#6 greg.ercolano
12:24 Aug 13, 2013
Are you opening the application over a remote X window connection?
Or are you using a remote desktop to access the machine in the
'working from home' case, ie. running the app on the same machine
as the display, and seeing the display over remote desktop?

These are important details.

Also: what happens when you run one of the FLTK opengl demos
this way, eg. the 'test/cube' demo? Does it misbehave similary?
Try to take octave out of the equation.
 
 
#7 muhali
07:45 Aug 14, 2013
> Are you opening the application over a remote X window connection?

yes, I am using an ssh tunnel.


> Also: what happens when you run one of the FLTK opengl demos

If LIBGL_ALWAYS_INDIRECT is set I can see things ('fractals', 'CubeView', etc.); if not, I get the notorious 'Insufficient GL support' but no output. In both cases no segfault.
 
 
#8 greg.ercolano
04:20 Aug 15, 2013
OK, the crash is because the private member Fl_Gl_Window::g is NULL,
and this is because FLTK was unable to to establish opengl in the
Fl_Gl_Window::show() method, and causing the "Insufficient GL support"
message (see "<---" below)

--- snip
void Fl_Gl_Window::show() {
#if defined(__APPLE__)
  int need_redraw = 0;
#endif
  if (!shown()) {
    if (!g) {
      g = Fl_Gl_Choice::find(mode_,alist);

      if (!g && (mode_ & FL_DOUBLE) == FL_SINGLE) {
        g = Fl_Gl_Choice::find(mode_ | FL_DOUBLE,alist);
        if (g) mode_ |= FL_FAKE_SINGLE;
      }

      if (!g) {
        Fl::error("Insufficient GL support");   <---
        return;
      }
--- snip

We could try to check 'g' for NULL everywhere and try to 'ignore'
it to prevent the app from crashing. (Need input on other devs on this)

But arguably, the application might be missing opportunities to detect
lack of opengl support and handle it gracefully. Some approaches to consider:

    1) The "Insufficient GL support" error can be caught by the app
       by setting an error handler for Fl::error to detect that message
       and act conditionally

    2) Perhaps the Fl_Gl_Window::can_do() function can be utilized here
       to detect the problem before it even gets to the "Insufficient GL support"
       Fl::error message

It would be good if the app were to detect lack of opengl support
as early in the opengl window creation process as possible, to prevent
further opengl manipulation.
 
 
#9 ianmacarthur
15:36 Mar 11, 2014
Hmm, I'm inclined to suggest that the octave folks might have coded a bit more defensively, I think fltk is *trying* to say there's not enough GL-ability and failing... But...?  
 
#10 ianmacarthur
15:48 Sep 04, 2014
Ping: any thoughts on this? Do we want to add some defensive code in fltk, or just close it as "won't fix" for now ...?  
 
#11 AlbrechtS
17:36 Apr 25, 2015
I suggest to close the STR.

The referenced octave bug report is closed meanwhile.
http://savannah.gnu.org/bugs/?31882

If I read the description correctly they use(d) an invisible (hidden) window to draw with OpenGL to use the result for "plotting", whatever this means in this context (I assume this is not meant to use a real "physical" plotter device). Hidden windows don't have a GL context, and that caused the crash in octave - or something like that. I may be completely wrong though. Anyway...

I can also add another point: as the OP I'm using an ssh connection from my Windows host machine to my Linux guest in a Virtualbox VM. I can use the VM's standard display (console) to run FLTK's OpenGL apps, but when I launch for instance test/glpuzzle from the Windows end of the ssh session (with X forwarding and a Cygwin X server) then I get as the OP described:

$ test/glpuzzle
Insufficient GL support
...

but if I set the environment variable LIBGL_ALWAYS_INDIRECT as in:

$ LIBGL_ALWAYS_INDIRECT=1 test/glpuzzle

then I don't get an error message, and the glpuzzle app works as expected.

More information:
<http://unix.stackexchange.com/questions/1437/what-does-libgl-always-indirect-1-actually-do>

The original bug appears to be solved, hence we should close this STR.


Any objections? Otherwise I'll close the STR in a few days.
 
 
#12 AlbrechtS
06:42 May 09, 2015
Closed, since original (octave) bug report was fixed.  
     

Return to Bugs & Features ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.