STR #3458

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 | Post Text | Post File | Prev | Next ]

STR #3458

Application:FLTK Library
Status:5 - New
Priority:3 - Moderate, e.g. unable to compile the software
Scope:3 - Applies to all machines and operating systems
Subsystem:GLUT Emulation
Summary:GLUT compatibility mode segfaults when there's no current window
Created By:bschack
Assigned To:Unassigned
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size top right image
#1 bschack
20:35 Mar 31, 2018
#2 bschack
18:35 Apr 03, 2018
bottom left image   bottom right image

Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
#1 bschack
19:20 Mar 30, 2018
When using GLUT compatibility mode, it's possible for there to be no current window - for example, when multiple windows have been created and the current one is deleted.  In that case, FLTK correctly sets the current window to NULL.  However, many functions (eg, glutGetWindow) always assume there's a current window, and in that case will try to dereference a NULL pointer, crashing as a result.  GLUT (and presumably FreeGLUT), handle such cases more gracefully.  For example, calling GLUT's glutGetWindow() with no current window returns 0.

Below is a trivial piece of code that illustrates some of the problems.  It's not very realistic, since it doesn't create any windows, but it's much more concise than creating multiple windows, with the same effects.

int main(int argc, char *argv)
    // GLUT - prints 0
    // FLTK - segmentation fault
    printf("%d\n", glutGetWindow());

    // GLUT - NOP
    // FLTK - segmentation fault

    // GLUT - produces warning
    // FLTK - segmentation fault

    return 0;
#2 AlbrechtS
01:20 Mar 31, 2018
Thanks for the report and the test code. Can you please provide full sample code that can be compiled and linked, preferable with build instructions (use "Post File")? This would help to test and fix FLTK's code to handle this case. TIA.  
#3 bschack
20:36 Mar 31, 2018
Added a complete file - let me know if you have any questions or problems with it.  Note that the GLUT stuff is written for OS X - for other systems the incantation will have to change, but I only have access to an Apple.  
#4 AlbrechtS
10:32 Apr 02, 2018
Thanks for the full sample program. I could compile and run it on Linux with both the FLTK glut emulation and FreeGlut. I'm looking further into it...

I modified the test program slightly. Here is an example output:

freeglut  ERROR:  Function <glutSetWindow> called without first calling 'glutInit'.

So where you wrote "GLUT - produces warning" this is an ERROR (program is terminated) in FreeGlut. In this particular case the error message is indeed confusing. The same kind of error would (should) happen if the index (7) is wrong (but 'glutInit' *was* called previously).

I'm not sure what errors we can handle more gracefully (and what error message we should generate). I tested error handling with Fl::fatal() like so:

FLTK ERROR: glutSetWindow() called without current glut window.

At this time I'm not sure what Fl::fatal() would exactly do an other platforms, namely on Windows, but I'll check this.

Would such an error handling be okay for you?
#5 bschack
18:35 Apr 03, 2018
I wrote an expanded program to test more functions, and compiled it on
3 systems:

(1) GLUT version 3.7 (was packaged with OS X; now deprecated)

(2) FreeGLUT 3.0.0

(3) FLTK's GLUT compatibility mode (FLTK 1.3.4)

In broad terms, I would characterize their error-handling philosophies

(1) Quietly ignore what can be ignored

(2) Issue errors and quit

(3) Crash

As for my preference, I tend to like the GLUT philosophy, but I can
see there being an argument for the FreeGLUT philosophy as well.  As
long as FLTK is consistent, I'm happy with either.  I'm not thrilled
with FLTK's current philosophy. :-)

I should note that the Mac implementation of FreeGLUT seems unstable -
sometimes a program will run without complaint one time, then produce
a bunch of errors and fail the next, with no changes or recompilation
in between.  So, I wouldn't completely trust my FreeGLUT test results.
I think my general impression of FreeGLUT's philosophy is correct

My expanded program (included as big.cxx) tests every function I could
find in FLTK that uses glut_window without first checking if it's
null.  Remember that when glutDestroyWindow() is called with the
current window, FLTK (correctly) sets glut_window to NULL.  So, in my
opinion, FLTK code *must* check for a NULL glut_window before
dereferencing it.  What we do when we find a NULL pointer is the
question.  As mentioned before, I'm happy with either GLUT's or
FreeGLUT's philosophy, as long as we're consistent.

Having said that, there is one function that needs to be changed, and
in a specific way: glutGetWindow().  According to the documentation,
it returns the identifier of the current window, zero otherwise.  That
means it should look like this:

inline int glutGetWindow()
    if (glut_window) {
        return glut_window->number;
    } else {
        return 0;

I hope this helps!
#6 AlbrechtS
07:51 Jan 01, 2019
Reduced priority to 3 (moderate).

This issue should not block the release of FLTK 1.3.5.
bottom left image   bottom right image

Return to Bugs & Features | Post Text | Post File ]


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