Crash when trying to add the first node

[jtsiomb]

I'm trying dust3d on a GNU/Linux 64bit system, and it just crashes when I click on the "+" tool and click on the screen to place it. Here's a stack trace when that happens:

#0  0x00007ffff66ac090 in QOpenGLContext::shareGroup() const () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#1  0x00007ffff69bec3a in QOpenGLFunctions::initializeOpenGLFunctions() () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#2  0x00007ffff69c2b2d in QOpenGLFramebufferObject::QOpenGLFramebufferObject(QSize const&, QOpenGLFramebufferObjectFormat const&) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#3  0x000055555558acb0 in ModelOfflineRender::toImage (this=0x555555ade960, size=...) at src/modelofflinerender.cpp:52
#4  0x000055555560b090 in MeshGenerator::process (this=0x555555ca4330) at src/meshgenerator.cpp:377
#5  0x00005555555b4d35 in QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, void (MeshGenerator::*)()>::call(void (MeshGenerator::*)(), MeshGenerator*, void**) (
    f=(void (MeshGenerator::*)(MeshGenerator * const)) 0x555555608e9e <MeshGenerator::process()>, o=0x555555ca4330, 
    arg=0x7fffdc913970) at ../../../include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:136
#6  0x00005555555b283f in QtPrivate::FunctionPointer<void (MeshGenerator::*)()>::call<QtPrivate::List<>, void>(void (MeshGenerator::*)(), MeshGenerator*, void**) (
    f=(void (MeshGenerator::*)(MeshGenerator * const)) 0x555555608e9e <MeshGenerator::process()>, o=0x555555ca4330, 
    arg=0x7fffdc913970) at ../../../include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:169
#7  0x00005555555ad871 in QtPrivate::QSlotObject<void (MeshGenerator::*)(), QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) (which=1, this_=0x555555b60060, r=0x555555ca4330, a=0x7fffdc913970, ret=0x0)
    at ../../../include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:398
#8  0x00007ffff61352af in QMetaObject::activate(QObject*, int, int, void**) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x00007ffff5f184d7 in QThread::started(QThread::QPrivateSignal) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x00007ffff5f1eb36 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x00007ffff5bc9f2a in start_thread (arg=0x7fffdc914700) at pthread_create.c:463
#12 0x00007ffff57c9edf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

I attached a gzipped core dump core.gz

[huxingyi]

Hi, thanks for reporting. It is looks like a OpenGL environment related problem. I don't have a linux environment which could cause the crash, and it's not crashing in the VirtualBox guest linux. Could you help to trace this issue when you have time please? maybe try other Qt versions. Thanks in advance.

[jtsiomb]

It would be helpful if you examined the state at the time of the crash using the core dump I attached, before trying random desperate things like different Qt versions. If you find something strange in the core dump and you want me to try something specific that will help you further, let me know.

[huxingyi]

Thanks, there is no strange things could found in the crash point. I will make a minimized project including the OpenGL stuff to limit the possible range of issue and ping you for help once it's done.

[huxingyi]

Hi, @jtsiomb may I know your qt version please? According to this qt blog post, qt have introduced threaded OpenGL since 4.8, and before that version, the OpenGL related Qt class is not thread safe.

Unfortunately that wasn’t possible because those Qt classes were not thread-safe. With Qt 4.8, this has changed and we have now added support for a few of the most common scenarios.

Dust3D is using a separate thread to do the offline rendering of parts, that could be a problem on Qt less than 4.8 version.

Also I have made a minimized threaded GL example project minimizedthreadedgl.zip, could you help me to test it and see if it still crash, thanks.

Usage:

Unzip minimizedthreadedgl.zip
$ cd minimizedthreadedgl
$ qmake
$ make

Run generated minimizedthreadedgl to see if it crash in none-threaded mode.

Change the define to 1 in main.cpp

#define ENABLE_THREADED_OPENGL  1

Make and run again to see if it crash in threaded mode.

If everything works fine, you should see a red triangle showed in the window.

If crash happened, that could be some Qt OpenGL bug, and we could look into it further. Thanks in advance.

[jtsiomb]

I have Qt 5.10.1 installed, and the program you gave me crashes regardless of whether ENABLE_THREADED_OPENGL is 0 or 1, in exactly the same manner, in the call to QOpenGLContext::shareGroup(), like the original backtrace above.

[huxingyi]

Thanks, so it's not thread safe related problem. There is another example code which come from Qt official website: textureinthread.zip Could you help to see if it runs on your machine when you have time please?

[jtsiomb]

That's a QtQuick/QML example program. Are you using QML? If not, I don't think this is going to help. Furthermore it tries to include private Qt headers which I don't have.

[huxingyi]

I am not using QML, but QOpenGLFramebufferObject, the same as the official example. Actually, my offline render code was modified from this example.

Please remove those lines from main.cpp, it should not affect the result but skip the check.

#include <QtGui/private/qguiapplication_p.h>
#include <QtGui/qpa/qplatformintegration.h>

if (!QGuiApplicationPrivate::platform_integration->hasCapability(QPlatformIntegration::ThreadedOpenGL)) {
        QQuickView view;
        view.setSource(QUrl("qrc:///scenegraph/textureinthread/error.qml"));
        view.show();
        return app.exec();
    }

If this example runs on your machine without problem, than we can compare this example with my code line by line, otherwise it's a Qt bug.

[jtsiomb]

It works fine, doesn't crash.

[huxingyi]

Thanks, that's a good news. I will compare the difference of QOpenGLFramebufferObject using with the example.

[huxingyi]

Hi, @jtsiomb I guess the problem is lack of QOpenGLContext::shareContext() in my code. Could you help to test again when you have time please, thanks in advance.

Code is here, in the parttree branch, this branch will merge back in the near future. https://github.com/huxingyi/dust3d/archive/805d0418995fb1edce839fc63933ecc7a27aefd2.zip

[jtsiomb]

Unfortunately it stil crashes in exactly the same way. Also I grepped for shareContext in your code and I can't find it. Unless it's implicitly called somewhere by some constructor.

[huxingyi]

My bad, should grep setShareContext, change is here, setShareContext from a QOpenGLWidget.

May I known what exactly version of GNU/Linux are you using please? I want install a VirtualBox guest to reproduce it instead of guessing :-)

Thanks.

[jtsiomb]

I'm running debian sid (unstable), on a pc with an intel core i5 6600 processor, and an nvidia geforce 1060 graphics card, using the nvidia proprietary drivers v390.67.

[jtsiomb]

I also tried it on my laptop with an intel GPU, also running debian sid, and it works fine. It might be some interaction with the nvidia driver, which probably means you won't reproduce it in a VM.

[huxingyi]

You are right, it works fine in my debian VM. However, the official example code runs well on your machine, so there must be also some problem in my code.

[huxingyi]

Hi, @jtsiomb I have removed the offline parts render, instead, I show the parts preview directly using OpenGL widget. So, the crash should gone because the code where crash happened has been removed. Could you help to verify if it still crash on the latest master branch please? Thanks in advance.

[jtsiomb]

Indeed it no longer crashes when adding a node.

[huxingyi]

Thanks for verify!