crash on startup: Ubuntu 16.04, Qt 5.9.2, Intel integrated graphics

[doug-moen]

The crash occurs using the latest source code, but a snapshot from April had the same problem.

Here's the GDB trace. I modified the CMakeLists.txt file to perform a Debug build, in order to get a better stack trace. This trace is not different from the Release build trace, except it has better line number information:

Thread 1 "Fragmentarium-2" received signal SIGSEGV, Segmentation fault.
0x000000000049596f in QOpenGLFunctions_4_1_Compatibility::glGetString (
    this=0x9b2830, name=7936)
    at /usr/local/Qt5.9.2/5.9.2/gcc_64/include/QtGui/qopenglfunctions_4_1_compatibility.h:1088
1088        return d_1_0_Core->f.GetString(name);
(gdb) bt
#0  0x000000000049596f in QOpenGLFunctions_4_1_Compatibility::glGetString (
    this=0x9b2830, name=7936)
    at /usr/local/Qt5.9.2/5.9.2/gcc_64/include/QtGui/qopenglfunctions_4_1_compatibility.h:1088
#1  0x00000000004864ad in Fragmentarium::GUI::DisplayWidget::initializeGL (
    this=0x9b2800)
    at /home/doug/res/src/FragM/Fragmentarium-Source/Fragmentarium/GUI/DisplayWidget.cpp:84
#2  0x00007ffff74dec1d in ?? ()
   from /usr/local/Qt5.9.2/5.9.2/gcc_64/lib/libQt5Widgets.so.5
#3  0x00007ffff74ded3a in QOpenGLWidget::resizeEvent(QResizeEvent*) ()
   from /usr/local/Qt5.9.2/5.9.2/gcc_64/lib/libQt5Widgets.so.5
#4  0x00007ffff74c1152 in QWidget::event(QEvent*) ()
   from /usr/local/Qt5.9.2/5.9.2/gcc_64/lib/libQt5Widgets.so.5
#5  0x00007ffff74845ec in QApplicationPrivate::notify_helper(QObject*, QEvent*)
    () from /usr/local/Qt5.9.2/5.9.2/gcc_64/lib/libQt5Widgets.so.5
#6  0x00007ffff748ba17 in QApplication::notify(QObject*, QEvent*) ()
   from /usr/local/Qt5.9.2/5.9.2/gcc_64/lib/libQt5Widgets.so.5
#7  0x00007ffff5ffe2b8 in QCoreApplication::notifyInternal2(QObject*, QEvent*)
    () from /usr/local/Qt5.9.2/5.9.2/gcc_64/lib/libQt5Core.so.5
#8  0x00007ffff74b9e02 in QWidgetPrivate::sendPendingMoveAndResizeEvents(bool, bool) () from /usr/local/Qt5.9.2/5.9.2/gcc_64/lib/libQt5Widgets.so.5
#9  0x00007ffff74bd843 in QWidgetPrivate::show_helper() ()
   from /usr/local/Qt5.9.2/5.9.2/gcc_64/lib/libQt5Widgets.so.5
#10 0x00007ffff74bd7e7 in QWidgetPrivate::showChildren(bool) ()
   from /usr/local/Qt5.9.2/5.9.2/gcc_64/lib/libQt5Widgets.so.5
#11 0x00007ffff74bd85f in QWidgetPrivate::show_helper() ()
   from /usr/local/Qt5.9.2/5.9.2/gcc_64/lib/libQt5Widgets.so.5
#12 0x00007ffff74c0505 in QWidget::setVisible(bool) ()
   from /usr/local/Qt5.9.2/5.9.2/gcc_64/lib/libQt5Widgets.so.5
#13 0x00007ffff74bd7f8 in QWidgetPrivate::showChildren(bool) ()
   from /usr/local/Qt5.9.2/5.9.2/gcc_64/lib/libQt5Widgets.so.5
#14 0x00007ffff74bd85f in QWidgetPrivate::show_helper() ()
   from /usr/local/Qt5.9.2/5.9.2/gcc_64/lib/libQt5Widgets.so.5
#15 0x00007ffff74c0505 in QWidget::setVisible(bool) ()
   from /usr/local/Qt5.9.2/5.9.2/gcc_64/lib/libQt5Widgets.so.5
#16 0x00007ffff74bd7f8 in QWidgetPrivate::showChildren(bool) ()
   from /usr/local/Qt5.9.2/5.9.2/gcc_64/lib/libQt5Widgets.so.5
#17 0x00007ffff74bd85f in QWidgetPrivate::show_helper() ()
   from /usr/local/Qt5.9.2/5.9.2/gcc_64/lib/libQt5Widgets.so.5
#18 0x00007ffff74c0505 in QWidget::setVisible(bool) ()
   from /usr/local/Qt5.9.2/5.9.2/gcc_64/lib/libQt5Widgets.so.5
#19 0x000000000047a8b9 in main (argc=1, argv=0x7fffffffdd18)
    at /home/doug/res/src/FragM/Fragmentarium-Source/Fragmentarium/Main.cpp:137

Some information about my GPU and driver, from glxinfo:

OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Desktop 
OpenGL core profile version string: 4.2 (Core Profile) Mesa 18.0.5

[3Dickulus]

I don't think this is a problem with FragM code.

check in file xorg.conf for...

Section "DRI" mode 0666 EndSection

the mode may be different for your setup.

FragM uses some specialized tricks, works very well on nVidia cards using the drivers supplied by nVidia. Mesa (software renderer) and nouveau (opensource GL driver) are not guaranteed to work, your card should support GL 4.1 compatibility profile for best results.

search "problem Intel GPU glGetString" on google for more information.

[claudeha]

Try setting the environment MESA_GL_VERSION_OVERRIDE=4.6COMPAT, this may allow FragM to start, and postpone the crash until new features are really used.

IMHO segfault is always a bug and should be fixed, even if it is just to print a message and abort().

[doug-moen]

@claudeha Thanks. An error message indicating that my driver doesn't support the right version of OpenGL, and telling me what version is needed, would have been helpful. On my system, glxinfo says:

Max core profile version: 4.2
Max compat profile version: 3.0

So if version 4.6 is the actual requirement, then I need to install a more recent GPU driver.

The "MESA_GL_VERSION_OVERRIDE=4.6COMPAT" trick works. It gets far enough to open a GUI window without crashing.

"MESA_GL_VERSION_OVERRIDE=4.1COMPAT" also works, and 3Dickulus did say that the requirement is OpenGL 4.1 compat.

This crashes with a core dump: "MESA_GL_VERSION_OVERRIDE=4.0COMPAT".

[3Dickulus]

in the code it requests 4.1 compat but after initialization, on nv gt760, it returns 4.6 compat ??? Qt says this is the best way to do it for the widest compatibility guaranteeing that you get a version that encompasses the requested version.

[doug-moen]

"Compat" means backward compatible with OpenGL 2.1 and earlier, it doesn't mean compatible with more GPUs. On the Macintosh, you can't get a compatibility context more recent than 2.1, but you can get a 4.1 core context. Similarly, on Ubuntu 16.04 with the Intel driver, you can't get a compatibility context more recent than 3.0, but you can get a 4.2 core context. In my project, I switched from using a compatibility context to using a core context so that my code would run on a wider variety of systems.

You lose some old deprecated features when switching to a core context. So when I made this switch, I had to make a few code changes. In my fragment shader, the built-in variable "glFragColor" goes away, but variable names beginning with "gl" are reserved, so I had to replace it with an out variable of a different name:

• out vec4 oFragColour; // in GLSL
• glBindFragDataLocation(m_program, 0, "oFragColour"); // in C++

Also, in my vertex shader, the keywords "attribute" and "varying" changed to "in" and "out".

These changes are a bigger deal in Fragmentarium than in my project, due to all of the user-defined shaders, but maybe you would use the preprocessor to hide these GLSL name changes. Eg, #define gl_FragColor oFragColour.

[3Dickulus]

yes I understand, 4.6 compat covers everything in 4.1 core plus earlier deprecated stuff, guarantees that it will handle 4.1, that's a Qt quirk. I am also aware that Mac has setup their OS+hardware for core profile only even though they use nVidia and should support it, it doesn't support compat profile, however, when Qt requests a 4.1 compat profile MacOS will return a working 4.1 core profile so at least it's possible to debug and get things working.

Fragmentarium was started Nov 8 2010 so it's 8 years old now, converting over to new GL and GLSL standards will require a complete rewrite and loose compatibility with the entire shader base, a huge project to refactor all of the frags and/or engine internals, in order to maintain backward compatability while updating the current code would make a mess imho, so my solution? is to use FragM as a repository of ideas that can serve as a guide for a new version that is up to current standards and can exploit new features. I would also use glFragColor to replace gl_FragColor.

Also the transition from older QGL to newer QOpenGL has caused many issues, I have managed to write in double types, dvec2/3/4 etc., and fix a few problems with textures, QOpenGLShader does not support double types natively so I use glCalls to make it happen, it would be better to derive a custom shader class from QOpenGLShader and add all the things it lacks, but I'm just one guy with a fulltime job so if you would like to work on a rewrite or refactoring the existing code I would be happy to work with you on that.

[doug-moen]

Great, thanks for all of that context. And thanks for your work on Fragmentarium.

Actually, I'm already working on a new system called Curv, and I'm looking at Fragmentarium as a source of ideas. But it won't be compatible with Fragmentarium, since models are written in a pure functional language that is compiled to GLSL, not in GLSL itself. I've manually translated some Fragmentarium models into the Curv language, and I'm hoping to learn some tricks from the code, like how progressive rendering is done.

[3Dickulus]

that's the thing about coders, everyone wants to do their own thing, I had a look at Curv and it looks really interesting, a lot of potential there, it would be interesting to see if it could be used to create the user part of fragments in FragM, some of the original authors of fragments have released their code under various copyrights, most make no mention of any copyright as it's all experimental.