Engine: BSD: Address SIGSEGV error on Loading / Creating a Project

[bedwardly-down]

valgrind-log.zip

Description

The editor partially loads the project and then crashes after a few seconds. It immediately crashes after project creation.

Prerequisites

Was on the project selection screen waiting to open a project.

Steps to Reproduce

1. Build latest source code with CMake.
2. Install to the SDK build directory using gmake install
3. Run WorldEditor from inside of install-root/sdk/2024.2/freebsd/x86/bin/ directory
4. Load up or create new project.

Expected behavior:

Full editor loads.

Actual behavior:

Crashes while loading editor and engine.

Reproducibility:

Consistently.

Versions

Additional Information

I decided to run both gdb and Valgrind to get to the bottom of this. Attached is the Valgrind log.

Note the Invalid write of size 8 on line 400 and then the Address 0x70 is not stack'd on line 413. There's other errors but MaterialInstance::setTransform is the crashing function in both debugger applications.

[bedwardly-down]

I'm not fully sure how to fix this yet but this may be related to the crashes others have been running into.

[eprikazchikov]

Seems like the issue in Renderable::setMaterialsList some materials was nullptr and have not created an instance for it. Which leads to nullptr exception

[eprikazchikov]

Have added a checker. But I assume some standard resources was not installed properly because of CMake build

[bedwardly-down]

That's part of why I might attempt to build Qt from source. Many of the libraries (especially the standard ones outside of the current build system) are ports of the Linux ones. I noticed several Qt library related errors in that log

[eprikazchikov]

it's not related Qt. Please check resources dir in SDK

[bedwardly-down]

Running gmake install produces this:

CMake Error at build/cmake_install.cmake:45 (file):
  file INSTALL cannot find "/plugins/imageformats": No such file or
  directory.
Call Stack (most recent call first):
  cmake_install.cmake:48 (include)

and then it complains about not having a local Qt installation and errors out with that too if I comment this out in build/cmake_install.cmake

[eprikazchikov]

it's CMake issues imageformats is directory not file

[bedwardly-down]

There's no .embedded folder so it throws this also when loading: [ FileIO ] Can't open file .embedded/DefaultMesh.shader

[bedwardly-down]

Thank you for your patience, by the way. We got this. I implemented your current commit manually and still getting a crash but also it loaded a bit further. Debugging now

[eprikazchikov]

.embedded is "virtual" directory. it's means this resource located NOT in project directory. It has many inputs most of them in "resources" directory. Check SDK build from the archive which I mentioned yesterday

[bedwardly-down]

It's not in the Linux one. I'll try from the Windows archive.

[eprikazchikov]

[bedwardly-down]

I mean the .embedded doesn't exist. Should it? I've already copied that folder from the Linux archive. Copying from the Windows one to see if there's a difference

[eprikazchikov]

.embedded doesn't exist on disk. It's just alias which points to files in "resources" directory. I have added it to separate game project resources from basic ones.

[bedwardly-down]

Yeah, platform release doesn't matter in this case. It's in the code.

[bedwardly-down]

Implementing your fix and adding a couple more checks, I was able to get this stacktrace with gdb:

0x0000000823e8c516 in PipelineContext::draw(Camera*) ()
   from /home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/bin/../lib/libengine-editor.so
(gdb) backtrace 
#0  0x0000000823e8c516 in PipelineContext::draw(Camera*) ()
    at /home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/bin/../lib/libengine-editor.so
#1  0x0000000823ef3246 in RenderSystem::update(World*) ()
    at /home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/bin/../lib/libengine-editor.so
#2  0x000000089dad2358 in RenderGLSystem::update(World*) ()
    at /home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/bin/plugins/librendergl-editor.so
#3  0x0000000823ef370a in RenderSystem::renderOffscreen(World*, int, int) ()
    at /home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/bin/../lib/libengine-editor.so
#4  0x000000089dad23cb in RenderGLSystem::renderOffscreen(World*, int, int) ()
    at /home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/bin/plugins/librendergl-editor.so
#5  0x000000000032c6d1 in IconRender::render(QString const&, QString const&) ()
#6  0x0000000000332282 in ImportQueue::onImportFinished() ()
#7  0x0000000000333f2b in QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, void (ImportQueue::*)()>::call(void (ImportQueue::*)(), ImportQueue*, void**) ()
#8  0x0000000000333e9d in void QtPrivate::FunctionPointer<void (ImportQueue::*)()>::call<QtPrivate::List<>, void>(void (ImportQueue::*)(), ImportQueue*, void**) ()
#9  0x0000000000333de2 in QtPrivate::QSlotObject<void (ImportQueue::*)(), QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) ()
#10 0x000000082e656672 in ??? () at /usr/local/lib/qt5/libQt5Core.so.5
#11 0x0000000823f19fd5 in AssetManager::importFinished() ()
    at /home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/bin/../lib/libengine-editor.so
#12 0x0000000823e03a5f in AssetManager::onPerform() ()
    at /home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/bin/../lib/libengine-editor.so
#13 0x0000000823f19b08 in AssetManager::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) ()
    at /home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/bin/../lib/libengine-editor.so
#14 0x000000082e656736 in ??? () at /usr/local/lib/qt5/libQt5Core.so.5
#15 0x000000082e65b803 in QTimer::timerEvent(QTimerEvent*) () at /usr/local/lib/qt5/libQt5Core.so.5
#16 0x000000082e64b5b7 in QObject::event(QEvent*) () at /usr/local/lib/qt5/libQt5Core.so.5
#17 0x0000000827c99b43 in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
    at /usr/local/lib/qt5/libQt5Widgets.so.5
#18 0x0000000827c9aeee in QApplication::notify(QObject*, QEvent*) ()
    at /usr/local/lib/qt5/libQt5Widgets.so.5
#19 0x000000082e622df1 in QCoreApplication::notifyInternal2(QObject*, QEvent*) ()
    at /usr/local/lib/qt5/libQt5Core.so.5
#20 0x000000082e6748b4 in QTimerInfoList::activateTimers() () at /usr/local/lib/qt5/libQt5Core.so.5
#21 0x000000082e676381 in ??? () at /usr/local/lib/qt5/libQt5Core.so.5
#22 0x0000000837a13ee1 in ??? () at /usr/local/lib/libglib-2.0.so.0
#23 0x0000000837a1428f in ??? () at /usr/local/lib/libglib-2.0.so.0
#24 0x0000000837a14326 in g_main_context_iteration () at /usr/local/lib/libglib-2.0.so.0
#25 0x000000082e675915 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/local/lib/qt5/libQt5Core.so.5
#26 0x000000082e61f786 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
    at /usr/local/lib/qt5/libQt5Core.so.5
#27 0x000000082e623471 in QCoreApplication::exec() () at /usr/local/lib/qt5/libQt5Core.so.5
#28 0x000000000030d5d4 in main ()

[eprikazchikov]

I can assume pipeline was not fully loaded. Could you check if pipeline tools plugin loaded? Pipeline is a special game resource which describes the order to render image and tasks were needed to render it.

[bedwardly-down]

 [PluginManager] Can't load plugin: /home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/bin/plugins/libpipelinetools.so
 [PluginManager] Can't load plugin: /home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/bin/plugins/libshadertools.so
 [PluginManager] Can't load plugin: /home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/bin/plugins/libmotiontools.so

Right on the money.

[bedwardly-down]

When I get off of work, I found some more places some checks can be added. Probably won’t fully solve the underlying problem but your suggestions have given me a direction on what to look for while I have downtime at work.

[eprikazchikov]

I think you should check dependencies for this plugins using ldd or analog on BSD platform. They all uses grapheditor module

[bedwardly-down]

Got it. I’ll still implement those checks locally since they won’t harm anything. There’s no library linkage errors left for the builds so far but I can recheck after work.

My assumptions are it’s the platform and system libraries first over your code for the same reasons you’ll suggest it’s directly related to your code and your build system. I’m enjoying working on this, to be honest. Thank you.😎

[eprikazchikov]

Yes it's bit addictive =)

[bedwardly-down]

Took a glance at the CMake files for all the unloaded plugins and they should link correctly. graph-editor is a dependency in all. I don’t have a Linux install right now but building a version with CMake and running natively from those builds could rule out if it’s the platform or the CMake build system. Getting a VM setup with an install to test on should be doable on my end. It doesn’t even need to run well, just be able to build and launch the editor.

[bedwardly-down]

That stacktrace brought up a Camera pointer. There’s at least one unchecked one in Pipelinecontext that could be null. I took a brief look at the RenderSystem and RenderGLSystem code and didn’t see anything right off the bat.

I’ll check the fonts too. The crash happens right after they get loaded in and sometimes they and certain image formats will get mangled by git when cloning from my experiences. It’s a known bug that pops up every so often with the git port on the platform.

[bedwardly-down]

When you setup the CMake system, did you assume a build inside tree or in an external folder? I think I found one of the problems.

I’m also confused about how the engine creates the virtual resource directory. I see the code looking for the resources and then assuming .embedded exists in memory. Definite black magic to me. That’s why I wasn’t sure if I should look for a hidden folder in the resources folder or not.

[bedwardly-down]

I think you should check dependencies for this plugins using ldd or analog on BSD platform. They all uses grapheditor module

Just got home from work. Here's the BSD libraries, plugins and executables ldd logs. There's nothing that's linked wrong as far as I can see. ldd-logs.zip

ldd-exe.log

[bedwardly-down]

My current assumption is that each of the failed plugins generated a warning of some type that I mindlessly didn't think much of. I'm building them individually and piping the warnings to a log. I'm also comparing my findings to the previous Linux build logs from your runners. I found some possible leads. Will post my findings here in a bit.

[bedwardly-down]

This doesn't exist in the other logs and is mighty suspicious to me:

/home/brad/git/thunder/engine/includes/editor/converters/animconverter.h:0: Note: No relevant classes found. No output generated.

Here's the source code for that: https://github.com/thunder-engine/thunder/blob/master/engine/includes/editor/converters/animconverter.h

pipeline-warnings.log

And attached is the warning log for pipelinetools. It's not generating all of the headers even though they have no issues with the Linux build.

Seems to be not relevant or useful. It's just a standard moc warning stating that it doesn't need to process that header.

[eprikazchikov]

When you setup the CMake system, did you assume a build inside tree or in an external folder? I think I found one of the problems.

I’m also confused about how the engine creates the virtual resource directory. I see the code looking for the resources and then assuming .embedded exists in memory. Definite black magic to me. That’s why I wasn’t sure if I should look for a hidden folder in the resources folder or not.

I think I forgot to prepare right install instructions fro CMake. Me personally using QBS because it's convenient to use it in Qt Creator IDE

[eprikazchikov]

I think you should check dependencies for this plugins using ldd or analog on BSD platform. They all uses grapheditor module

Just got home from work. Here's the BSD libraries, plugins and executables ldd logs. There's nothing that's linked wrong as far as I can see. ldd-logs.zip

ldd-exe.log

Ok seems like all dependencies were resolved. Then it's missilery why it don't loading =/

[eprikazchikov]

This doesn't exist in the other logs and is mighty suspicious to me:

/home/brad/git/thunder/engine/includes/editor/converters/animconverter.h:0: Note: No relevant classes found. No output generated.

Here's the source code for that: https://github.com/thunder-engine/thunder/blob/master/engine/includes/editor/converters/animconverter.h

pipeline-warnings.log

And attached is the warning log for pipelinetools. It's not generating all of the headers even though they have no issues with the Linux build.

Seems to be not relevant or useful. It's just a standard moc warning stating that it doesn't need to process that header.

I don't fully understand what relevant classes it's looking

[bedwardly-down]

This doesn't exist in the other logs and is mighty suspicious to me: /home/brad/git/thunder/engine/includes/editor/converters/animconverter.h:0: Note: No relevant classes found. No output generated. Here's the source code for that: https://github.com/thunder-engine/thunder/blob/master/engine/includes/editor/converters/animconverter.h pipeline-warnings.log And attached is the warning log for pipelinetools. It's not generating all of the headers even though they have no issues with the Linux build. Seems to be not relevant or useful. It's just a standard moc warning stating that it doesn't need to process that header.

I don't fully understand what relevant classes it's looking

When using AUTOMOC ON in CMake, it can be a harmless error if you don't want all headers to be MOC'd. On the other hand, if this is an actual issue, I'll look further into it.

Here's a 2019 bug report about it from the official forums: https://bugreports.qt.io/browse/QTBUG-77421 . MOC is very new to me and some sources say it's an issue, some don't, depending on what is needed by the developer.

[bedwardly-down]

When you setup the CMake system, did you assume a build inside tree or in an external folder? I think I found one of the problems. I’m also confused about how the engine creates the virtual resource directory. I see the code looking for the resources and then assuming .embedded exists in memory. Definite black magic to me. That’s why I wasn’t sure if I should look for a hidden folder in the resources folder or not.

I think I forgot to prepare right install instructions fro CMake. Me personally using QBS because it's convenient to use it in Qt Creator IDE

Honestly, I'm more comfortable with CMake and alternative systems like Facebook's Buck. I completely understand. Qt is very new to me overall so scripting with qbs is a bit of trial and error for me.

[eprikazchikov]

I would like to improve CMake with your help if u don't mind. It's a good feedback from you! Thank you!

[bedwardly-down]

Gladly. I won't have time this morning to fully work on #783 but getting the build systems worked out properly would greatly improve the project for users. Until the BSD port is in a more stable state, I won't be looking at porting that part of the build to qbs just yet. I don't want to introduce too many bugs to the other platforms and qbs not having an official binary build on FreeBSD (specifically) could mean problems for the end user.

[bedwardly-down]

I think you should check dependencies for this plugins using ldd or analog on BSD platform. They all uses grapheditor module

Just got home from work. Here's the BSD libraries, plugins and executables ldd logs. There's nothing that's linked wrong as far as I can see. ldd-logs.zip ldd-exe.log

Ok seems like all dependencies were resolved. Then it's missilery why it don't loading =/

I'm still looking further into this. My current new assumption is that either there's a bug in graph-editor that's depended on only by the unloaded plugins or one of the thirdparty dependencies they all share is causing problems.

An example test I've done so far that failed: I upgraded physfs to 3.2.0. It's fully backwards compatible with the original version used (it was created for use with I want to say the Linux port of Unreal Tournament 2003 - could be remembering wrong), so its maintainer (icculus) has kept it backwards compatible to support his old port jobs and a large number of retro and modern systems. That's heavily used in the resource loading system for Thunder.

[eprikazchikov]

graph-editor depending on uikit and qt.

[bedwardly-down]

I was meaning you may have been on point with asking me to check graph-editor. All of the failed plugins depend on graph-editor but it's also possible it could be uikit or one of the shared third-party dependencies. I like to make broad assumptions and then narrow them down.

[eprikazchikov]

is it possible to check plugins dependencies in hierarchy way?

[bedwardly-down]

I can try. It's definitely a weakness.

[bedwardly-down]

I don't know how useful this is but all of the plugins that won't load (minus UIKit) have errors where the module name and information is in the compiled library. These are specific dumps from those. With how modules are loaded, I noticed that you seem to look for just the basic information and then load from there. I could be misreading, but your code flows well.

dump.txt

These only seem to exist for these plugins but I haven't dove too far into all of them. These also don't exist in the Linux or Windows counterparts from the Github runner builds.

[bedwardly-down]

It's Independence Day here but I didn't feel like going out. I took a several hour nap instead. I had this dream about a possible fix and I'm testing it out right now. The runtime path (RPATH) for Linux and FreeBSD must be configured slightly differently.

Example: a library needs to call another library in its same directory. Linux automatically links them correctly. FreeBSD didn't in this case, hence a possible reason for the plugins not properly loading. What I've noticed is they don't load when I run from the sdk build but do load when running from the build directory before install.

FreeBSD

brad@5k-lame-brain ~/g/t/i/s/2/f/x/b/plugins [1]> ldd libshadertools.so | grep editor
ldd: libshadertools.so: Shared object "libshadertools.so" not found, required by "ldd"
libshadertools.so: exit status 1

Linux

brad@5k-lame-brain ~/D/T/l/r/i/s/2/l/x/b/plugins> /compat/linux/bin/bash ldd libshadertools.so | grep editor
    libgraph-editor.so => /home/brad/Downloads/Thunder/linux/release/install-root/sdk/2024.2/linux/x86_64/bin/plugins/./../../lib/libgraph-editor.so (0x0000000801243000)
    libengine-editor.so => /home/brad/Downloads/Thunder/linux/release/install-root/sdk/2024.2/linux/x86_64/bin/plugins/./../../lib/libengine-editor.so (0x0000000801c00000)
    libnext-editor.so => /home/brad/Downloads/Thunder/linux/release/install-root/sdk/2024.2/linux/x86_64/bin/plugins/./../../lib/libnext-editor.so (0x00000008012da000)
    libuikit-editor.so => /home/brad/Downloads/Thunder/linux/release/install-root/sdk/2024.2/linux/x86_64/bin/plugins/./../../lib/../lib/libuikit-editor.so (0x0000000801a7c000)
    libphysfs-editor.so => /home/brad/Downloads/Thunder/linux/release/install-root/sdk/2024.2/linux/x86_64/bin/plugins/./../../lib/../lib/libphysfs-editor.so (0x000000080139b000)
    libglfw-editor.so => /home/brad/Downloads/Thunder/linux/release/install-root/sdk/2024.2/linux/x86_64/bin/plugins/./../../lib/../lib/libglfw-editor.so (0x00000008024e1000)
    libfreetype-editor.so => /home/brad/Downloads/Thunder/linux/release/install-root/sdk/2024.2/linux/x86_64/bin/plugins/./../../lib/../lib/libfreetype-editor.so (0x000000080283e000)
    libzlib-editor.so => /home/brad/Downloads/Thunder/linux/release/install-root/sdk/2024.2/linux/x86_64/bin/plugins/./../../lib/../lib/../lib/libzlib-editor.so (0x00000008013b2000)

UPDATE: Not worried about this one. It didn't make much difference in this case. But I do see another possible fix. All of these are not in the code but its dependencies due to observing the plugins possibly loading correctly otherwise (no plugin not loading warning that is)

[bedwardly-down]

I keep looking at the code and don't see anything that would directly be problematic so far but also am not as familiar with much of what's used, so I'm learning as I go. Doing extra checks for nullptrs hides but doesn't solve the problem of the plugins not loading. Those plugins are most likely why the shader and pipeline files won't load. Fonts and textures are loading though (according to this):

 [PluginManager] Can't load plugin: /home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/bin/uikit-editor.so
 [PluginManager] Can't load plugin: /home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/bin/plugins/libmotiontools.so
 [PluginManager] Can't load plugin: /home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/bin/plugins/libshadertools.so
 [PluginManager] Can't load plugin: /home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/bin/plugins/libpipelinetools.so
 Converting: /home/brad/git/thunder-build/install-root/sdk/2024.2/resources/editor/gizmos/camera.png
 Converting: /home/brad/git/thunder-build/install-root/sdk/2024.2/resources/editor/gizmos/directlight.png
 Converting: /home/brad/git/thunder-build/install-root/sdk/2024.2/resources/editor/gizmos/pointlight.png
 Converting: /home/brad/git/thunder-build/install-root/sdk/2024.2/resources/editor/gizmos/spotlight.png
 Converting: /home/brad/git/thunder-build/install-root/sdk/2024.2/resources/engine/textures/invalid.png
 Converting: /home/brad/git/thunder-build/install-root/s
dk/2024.2/resources/editor/gizmos/postprocess.png
 Converting: /home/brad/git/thunder-build/install-root/sdk/2024.2/resources/editor/gizmos/soundsource.png
 Converting: /home/brad/git/thunder-build/install-root/sdk/2024.2/resources/engine/textures/ui.png
 Converting: /home/brad/git/thunder-build/install-root/sdk/2024.2/resources/engine/fonts/Roboto.ttf
 [ FileIO ] Can't open file .embedded/DefaultMesh.shader
 Converting: /home/brad/git/thunder-build/install-root/sdk/2024.2/resources/engine/meshes/cube.fbx
 [ FileIO ] Can't open file .embedded/DefaultMesh.shader
 Converting: /home/brad/git/thunder-build/install-root/sdk/2024.2/resources/engine/meshes/plane.fbx
 [ FileIO ] Can't open file .embedded/DefaultMesh.shader
 Converting: /home/brad/git/thunder-build/install-root/sdk/2024.2/resources/editor/meshes/cone.fbx
 [ FileIO ] Can't open file .embedded/DefaultMesh.shader
 Converting: /home/brad/git/thunder-build/install-root/sdk/2024.2/resources/editor/meshes/bone.fbx
 [ FileIO ] Can't open file .embedded/DefaultMesh.shader
 Converting: /home/brad/git/thunder-build/install-root/sdk/2024.2/resources/editor/meshes/sphere.fbx
 [ FileIO ] Can't open file .embedded/DirectLight.shader
 [ FileIO ] Can't open file .embedded/DefaultSprite.shader
 [ FileIO ] Can't open file .embedded/DefaultSprite.shader
 [ FileIO ] Can't open file .embedded/DefaultPostEffect.shader
 [ FileIO ] Can't open file .embedded/Deferred.pipeline
fish: Job 1, './install-root/sdk/2024.2/freeb…' terminated by signal SIGSEGV (Address boundary error)

[bedwardly-down]

I don't know how useful this is but all of the plugins that won't load (minus UIKit) have errors where the module name and information is in the compiled library. These are specific dumps from those. With how modules are loaded, I noticed that you seem to look for just the basic information and then load from there. I could be misreading, but your code flows well.

dump.txt

These only seem to exist for these plugins but I haven't dove too far into all of them. These also don't exist in the Linux or Windows counterparts from the Github runner builds.

I have it in a separate branch, but upgrading glslang from 11.8.0 to 11.13.0 didn't solve the shadertools plugin not loading issue. I've gotten some feedback from the BSD porting community on the dumps and outside of the iterator warning, they're probably not related to the core cause. Main piece of feedback that stood out to me:

What I'm saying is valid syntax in one version of the SPIR-V compiler might not be valid in another. That does not necessarily mean you have to upgrade anything, but that might explain the observed difference between platforms.

Getting this solved would still possibly need some shader tweaks to get fully working.

[bedwardly-down]

I'm not sure if this is a hit or not, but all of the modules that have load problems are the only ones that share a graph-editor dependency, specifically the abstractnodegraph.h and graphnode.h headers.

brad@5k-lame-brain ~/g/thunder (embedded-black-magic-2)> grep -uwR modules/editor/* --exclude-dir=modules/editor/grapheditor -e "graph" | grep "\.h"
modules/editor/motiontools/editor/animationedit.ui:   <header>editor/graph/graphview.h</header>
modules/editor/motiontools/converter/entrystate.h:#include <editor/graph/abstractnodegraph.h>
modules/editor/motiontools/converter/animationcontrollergraph.h:#include <editor/graph/abstractnodegraph.h>
modules/editor/pipelinetools/editor/pipelineedit.ui:   <header>editor/graph/graphview.h</header>
modules/editor/pipelinetools/converter/pipelinetaskgraph.h:#include <editor/graph/graphnode.h>
modules/editor/pipelinetools/converter/pipelinetaskgraph.h:#include <editor/graph/abstractnodegraph.h>
modules/editor/shadertools/converter/shadergraph.h:#include <editor/graph/graphnode.h>
modules/editor/shadertools/converter/shadergraph.h:#include <editor/graph/abstractnodegraph.h>
modules/editor/shadertools/converter/shadergraph.cpp:#include <editor/graph/nodegroup.h>
modules/editor/shadertools/converter/rootnode.h:#include <editor/graph/graphnode.h>
modules/editor/shadertools/converter/rootnode.h:#include <editor/graph/abstractnodegraph.h>
modules/editor/shadertools/converter/functions/function.h:#include <editor/graph/graphnode.h>
modules/editor/shadertools/editor/materialedit.ui:   <header>editor/graph/graphview.h</header>

Following this particular lead while drinking coffee and getting ready for work.

[eprikazchikov]

I can try. It's definitely a weakness.

Have found lddtree utility

https://stackoverflow.com/questions/1488527/hierarchical-ldd1

[eprikazchikov]

I don't know how useful this is but all of the plugins that won't load (minus UIKit) have errors where the module name and information is in the compiled library. These are specific dumps from those. With how modules are loaded, I noticed that you seem to look for just the basic information and then load from there. I could be misreading, but your code flows well. dump.txt These only seem to exist for these plugins but I haven't dove too far into all of them. These also don't exist in the Linux or Windows counterparts from the Github runner builds.

I have it in a separate branch, but upgrading glslang from 11.8.0 to 11.13.0 didn't solve the shadertools plugin not loading issue. I've gotten some feedback from the BSD porting community on the dumps and outside of the iterator warning, they're probably not related to the core cause. Main piece of feedback that stood out to me:

What I'm saying is valid syntax in one version of the SPIR-V compiler might not be valid in another. That does not necessarily mean you have to upgrade anything, but that might explain the observed difference between platforms.

Getting this solved would still possibly need some shader tweaks to get fully working.

You are not getting even close to shader compilation yet. If plugin "shadertools" will not loaded, it will not start to convert shaders. The update of GLSL version wiil not solve this problem. We need to understand what wrong with load.

[bedwardly-down]

I don't know how useful this is but all of the plugins that won't load (minus UIKit) have errors where the module name and information is in the compiled library. These are specific dumps from those. With how modules are loaded, I noticed that you seem to look for just the basic information and then load from there. I could be misreading, but your code flows well. dump.txt These only seem to exist for these plugins but I haven't dove too far into all of them. These also don't exist in the Linux or Windows counterparts from the Github runner builds.

I have it in a separate branch, but upgrading glslang from 11.8.0 to 11.13.0 didn't solve the shadertools plugin not loading issue. I've gotten some feedback from the BSD porting community on the dumps and outside of the iterator warning, they're probably not related to the core cause. Main piece of feedback that stood out to me: What I'm saying is valid syntax in one version of the SPIR-V compiler might not be valid in another. That does not necessarily mean you have to upgrade anything, but that might explain the observed difference between platforms. Getting this solved would still possibly need some shader tweaks to get fully working.

You are not getting even close to shader compilation yet. If plugin "shadertools" will not loaded, it will not start to convert shaders. The update of GLSL version wiil not solve this problem. We need to understand what wrong with load.

My thoughts exactly. It was feedback I was given for a possible issue that will come after.

[bedwardly-down]

I can try. It's definitely a weakness.

Have found lddtree utility

https://stackoverflow.com/questions/1488527/hierarchical-ldd1

Thanks for sharing that. Would that help you out on seeing what’s happening on my end? When you say hierarchy, tree makes more sense to me in this case. I’ll grab this after work. 🤘

[eprikazchikov]

Logs says clearly: [PluginManager] Can't load plugin: This means code bellow failed: QLibrary *lib = new QLibrary(path); if(lib->load()) {

Based on my experience with QT it happens when lib dependencies was not fully resolved. I think the issue is in RPATH for some of sub-dependecies. Do u have lddtree ?