| [ 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: | |
Trouble Report Files:
|
#1 | muhali 07:58 Aug 13, 2013 |
| dbg.txt 17k | |
Trouble Report Comments:
|
#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 ]
|
| |