#255 Freeglut 3.X - regression with glutSolidSphere, fgStructure.Cthe urrentWindow is NULL

[AntonG]

Debian/Ubuntu and co are still having the old 2.8.1 version of the freeglut. The only reason not to update is is the crash of the YADE-Software, when it is compiled and linked against any of Freeglut_3-versions.

I debugged it further and defined, that the crash was caused by calling the function glutSolidSphere in Yade. But the real problem happens in the Freeglut in fghDrawGeometrySolid-function just after calling the fgStructure.CurrentWindow, which is NULL at the moment.

https://github.com/dcnieho/FreeGLUT/blob/git_master/freeglut/freeglut/src/fg_geometry.c#L181

Yade's ticket is here:

https://gitlab.com/yade-dev/trunk/-/issues/155

Thanks

[John Tsiombikas]

I'm having some trouble undestanding what the issue you're reporting is. Is fgStructure.CurrentWindow null after having initialized freeglut and created a window? Or is it simply the case that this program calls glutSolidSphere without having first initialized freeglut? The fist would be a bug in freeglut, the second would be a bug in yade.

If this is indeed something wrong with freeglut, please elaborate, and also ideally post a minimal compilable test program which reproduces the bug so that we can reproduce and troubleshoot it.

[John Tsiombikas]

Closing as invalid due to lack of followup from OP. Feel free to reopen if you care to explain what the bug is about.

[Yathindu Hettiarachchige]

Hi, I've also bumped into the crash they are speaking about. I'm not using YADE but in my own project.

The crash happens in fghDrawGeometrySolid in line 185. fgStructure.CurrentWindow is NULL.

We do call glutInit, so I believe this could be a bug in freeglut.

[John Tsiombikas]

Have you created a window? If so, please post a minimal compilable program which reproduces the issue.

[AntonG]

In YADE we have recently merged a workaround [1]. Creating a dummy window
to prevent a crash. But it looks like a dirty hack, so the freeglut
will probably stay blocked in Debian/Ubuntu for a while due to this issue
(with old version 2.8.1).

It is still questionable, why it perfectly works with an old version
and crashes with a newer one.

[1] https://gitlab.com/yade-dev/trunk/-/merge_requests/747/diffs#3798c3f321ec79cf0e481af13db60d6dc2025a8d_29_30

Best regards

Anton

[John Tsiombikas]

Nobody explained what the issue is sufficiently well. Let me make another attempt at understanding it.

You call glutInit, but you don't create a window, and then proceed to call the primitive functions? And that leads to a crash due to CurrentWindow being null?

What is the point of calling any OpenGL functions without a window? Without a window there is no OpenGL context. Even if freeglut doesn't crash, nothing will happen.

Is the so called blocking bug just that freeglut crashes instead of checking that the window is null and deliberately aborting instead? Because we can certainly fix that part, but I don't see how that helps your program.

[AntonG]

Hi John,

thanks for analyzing it. You are probably right about this conclusion.
But the problem is that many codes rely on this behavior, which was before.

If you could provide at least a minimal patch which probably fixes the
issue in freeglut
without committing it into the main branch, we can test it and give
you feedback,
if it works or not.

Thank you

Anton

[Klaus Doll]

Hello,

we have had the same crash with a GUI for Molpro.
glutInit is called, but the windows are made with gtk ( gtk_window_new ).
glut is then used to draw spheres etc (to visualise atoms, bonds).
This worked with freeglut 2.8.1-8.4 in openSUSE-Leap-42.3-0 , but crashed
from openSUSE-Leap-15.0-1 onwards, with freeglut 3.0.0-lp150.1.8 .
It still works on Mac with GLUT.framework instead of freeglut.

I was in touch with the YADE group, as I had made a workaround, to open
a dummy window with glutCreateWindow . This avoids a crash, but is
certainly not a proper fix; e.g. the dummy window is visible on the
screen, may be enlarged, is shown iconised etc.
More details are on the link given in the description.

It would be great to avoid the crash, and make functions such as
glutSolidSphere etc work again, without relying on a window which
had been created with glutCreateWindow .

[John Tsiombikas]

Ok now I get it.

Let me be frank, I think this is completely innane, using freeglut just to draw spheres. Just write 20 lines of code to draw a sphere instead. But nevertheless, I'll take a look in the primitive drawing code and see if we can facilitate this usage. It should be possible.

My guess without looking at the code yet, is that it accesses the window to see if the user requested drawing using custom attribute locations (because the code has been rewritten to support OpenGL core profiles, where there is no fixed function pipeline and default vertex attributes). A reasonable approach would be to fall back to the default vertex attributes if the window pointer is null.

Re-opening the bug until I have a chance to look into this.

[AntonG]

Dear John,

thank you very much for fixing it! I have just patched our packaged
version and everything works even without workaround! Really
appreciate your help.

Are you planning to release a newer version soon? if not, we will patch
an older one and push into the Debian/Ubuntu.

Best regards

Anton

Am Mi., 22. Dez. 2021 um 23:01 Uhr schrieb John Tsiombikas
jtsiomb@users.sourceforge.net:

status: open --> closed-fixed
Comment:

fixed, svn revision 1868.

[John Tsiombikas]

I'll have to look through the svn revisions since the previous release to see what has changed, and if it warrants a new release, but it'll probably take some time to get things going. If patching the previous version in debian is an option, I suggest doing that for now to avoid being blocked waiting for this.

[AntonG]

Ok, thanks for the update. The patch is applied cleanly and
we can proceed with the transition.

Best regards

Anton

[John Tsiombikas]

fixed, svn revision 1868.

[Klaus Doll]

This is a bit late now, nevertheless:

I have built freeglut from source, and revision 1868 fixes the crash
for me as well. The workaround with creating a dummy window is not necessary
any more.

It would be nice when new binaries could also be released in due time.

Thank you very much John and also the Yade group, thank you Anton, Janek, Przemysław .