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]

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 ?

Grabbing it after work. You answered my previous question remarkably. RPATH is different between Linux and BSD for sure. I have some ideas after looking at RPATH with readelf

[bedwardly-down]

I’m a little surprised you weren’t using https://doc.qt.io/qt-5/qpluginloader.html but at the same time, rolling your own plugin system does give you more control and is one less thing that can fully break your system. I spent most of yesterday following the plugin structure and how you render the ui and everything else.

[eprikazchikov]

QPluginLoader is just a wrapper. Plugins in my case bit more specific. I'm not using Qt in game binaries. Editor only. But many modules can be used in game. So I was need more universal system in my case.

[bedwardly-down]

Makes perfect sense. Great explanation. I’ve noticed you limit QT usage to where it’s needed but that’s it. I don’t remember if I posted it but the crash stacktrace showed missing Qt implementations (hence part of why I thought about building it from source).

[eprikazchikov]

I would like to remove Qt completely one day. But unfortunately it's too far from this.

[bedwardly-down]

I’ll still peruse the grapheditor code while at work. I’m following that lead and using it to understand how it works since it’s a common thread that only the broken modules have. The Plugin specific code is uniform across the board, so it’s not an issue.

[bedwardly-down]

One thing I’m not sure about is how Qt would break these plugins but not cause the other ones to not load (unless they haven’t loaded because these ones failed to load). It might be good to implement extra logging for debugging when a plugin doesn’t load. Debug builds are helping some with finding why things aren’t working for me but having the extra information won’t hurt.

[eprikazchikov]

QLibrary just using syscalls to load library dynamically. If library can't be loaded (because of dependencies) it just returns nullptr handler. At least texturetools plugins is loading normally. In your case only 3 plugins is failed to load. All 3 has dependency graph-editor. It provides the editor of graphs. grapth-editor uses uikit to visualize this graphs. So I bet the issue is in paths to search this dependencies. probably you can check this two libs and it's rpaths

[bedwardly-down]

For your Linux binaries, RPATH directly adds the local QT’s internal gcc/lib directory to it. That’s the only thing I’m observing. Do you have alternatives for that if that isn’t the solution?

[bedwardly-down]

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

This is also not an issue. I tested again and the Linux ldd and BSD version handle paths slightly differently.

ldd ./libshadertools.so is the correct way on BSD while ldd libshadertools.so seems valid for the Linux tool.

[eprikazchikov]

For your Linux binaries, RPATH directly adds the local QT’s internal gcc/lib directory to it. That’s the only thing I’m observing. Do you have alternatives for that if that isn’t the solution?

The texturetools plugin is also using Qt inside. (It has a sprite editor). But loading correct.

[bedwardly-down]

I love how you have your directories structured. Having editor, components, resources, etc where needed in the modules helps quite a bit with readability. Everything with the editor subdirectory relies on Qt in some form.

[eprikazchikov]

please check where graph-editor and uikit-editor is located in your case?

[bedwardly-down]

For your Linux binaries, RPATH directly adds the local QT’s internal gcc/lib directory to it. That’s the only thing I’m observing. Do you have alternatives for that if that isn’t the solution?

The texturetools plugin is also using Qt inside. (It has a sprite editor). But loading correct.

Are you guiding me to the solution or guessing like me? Texturetools loading correctly using Qt is dependent on a difference in implementation of similar elements but aligns with where my train of thought was going.

I was asking for an alternative because you know your project better than me but keep on suggesting it’s the RPATH when my own tests are leaning me away from that.

[eprikazchikov]

For your Linux binaries, RPATH directly adds the local QT’s internal gcc/lib directory to it. That’s the only thing I’m observing. Do you have alternatives for that if that isn’t the solution?

The texturetools plugin is also using Qt inside. (It has a sprite editor). But loading correct.

Are you guiding me to the solution or guessing like me? Texturetools loading correctly using Qt is dependent on a difference in implementation of similar elements but aligns with where my train of thought was going.

I was asking for an alternative because you know your project better than me but keep on suggesting it’s the RPATH when my own tests are leaning me away from that.

Unfortunately guessing. I don't have BSD to check. But all points to RPATH. What is your assumptions?

[bedwardly-down]

For your Linux binaries, RPATH directly adds the local QT’s internal gcc/lib directory to it. That’s the only thing I’m observing. Do you have alternatives for that if that isn’t the solution?

The texturetools plugin is also using Qt inside. (It has a sprite editor). But loading correct.

Are you guiding me to the solution or guessing like me? Texturetools loading correctly using Qt is dependent on a difference in implementation of similar elements but aligns with where my train of thought was going. I was asking for an alternative because you know your project better than me but keep on suggesting it’s the RPATH when my own tests are leaning me away from that.

Unfortunately guessing. I don't have BSD to check. But all points to RPATH. What is your assumptions?

Not unfortunate at all. We’re on the same page then.

Most of the BSDs follow the standard Linux directory structures outside of where userland (ported tools and libraries that aren’t a part of the base go here) software goes. That’s what “/usr/local” is all about in my CMake updates.

The sdk structure and build directories will be the exact same between Linux and BSD.

My core assumption is that they’re not all three caused by the same source. My Assimp upgrade didn’t break the other platforms and the official port needed no patching to work and build, so it’s not likely that that’s the shadertools plugin loading (not a direct dependency but the resource loading relies on that as far as I can tell).

My current assumption is a dependency being finicky because the code compiles and builds properly for everything else but several of your third party libraries may require upgrading. I want to avoid that unless it’s a small version upgrade or required but will test against newer compatible versions if it rules out it being a known upstream issue that was fixed.

[bedwardly-down]

Another assumption would be Clang vs GCC. Mac’s clang and BSD’s are different under the hood, so what works correctly on a Mac won’t always translate to the BSD version. Gotta love custom flavors of tools. 😅

[eprikazchikov]

Could you make an archive of your install dir from cmake?

[bedwardly-down]

When I get off work, I can send it. It’ll be too big for Github. A debug build directory ends up at just under 1 GB in size. The sdk debug build I haven’t checked but release sdk is slightly smaller than the Linux one.

Would a Google drive link be ok?

[eprikazchikov]

I don't think the build dir will be useful for me. could you just zip an install dir?

[bedwardly-down]

I misread your original message. The sdk release install is slightly smaller than the Linux install. I might be able to manually add the system Qt libraries to it and them link correctly. I’ll need to test that out. Without them, lddtree will give the wrong info

[eprikazchikov]

Or you just can list install dir structure recursive for now. I just would like to check everything is in place. so you refer to Qt libs outside install dir right? this would require to change RPATH isn't it?

[bedwardly-down]

I haven’t tried it yet. I’m used to that being linked without any intervention. That’s why when some of the modules couldn’t find specific Qt modules it was strange.

[eprikazchikov]

I haven’t tried it yet. I’m used to that being linked without any intervention. That’s why when some of the modules couldn’t find specific Qt modules it was strange.

If you just building from source for you own it will work. but if you a going to make SDK you need to bundle all dependencies.

[bedwardly-down]

Heading home for lunch. Have about 3 hours before going back in so I’ll work with your feedback. If it’s as simple as that, I’ll be relieved. If not, I still have reading to do.

[bedwardly-down]

Or you just can list install dir structure recursive for now. I just would like to check everything is in place. so you refer to Qt libs outside install dir right? this would require to change RPATH isn't it?

tree.txt

Reverse tree incoming

[eprikazchikov]

I don't think it's an issue, but are you using x86 architecture?

[bedwardly-down]

I don't think it's an issue, but are you using x86 architecture?

64-bit. That's on my todo list. The way CMake currently determines architecture is a bit off. For FreeBSD 14.x and older, 32-bit support will remain actively supported upstream (don't know about the other BSDs) but 15+ is going exclusively 64-bit and dropping 32-bit (outside of compatibility requirements for certain software like WINE or some browsers). It shouldn't cause an issue for my tests but would be a problem if a maintainer from the repos takes on getting it officially in there.

See here: https://forums.freebsd.org/threads/heads-up-freebsd-is-stopping-all-32-bit-hardware-support-except-armv7.91811/

[eprikazchikov]

test.zip Please apply this patch. It will add an error string from qt to logs output

[bedwardly-down]

test.zip Please apply this patch

That is a beautiful patch. I just opened it and was :smiley:

[bedwardly-down]

 [PluginManager] Can't load plugin: /home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/bin/uikit-editor.so With error: Cannot load library /home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/bin/uikit-editor.so: (Cannot open "/home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/bin/libuikit-editor.so")
 [PluginManager] Can't load plugin: /home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/bin/plugins/libmotiontools.so With error: Cannot load library /home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/bin/plugins/libmotiontools.so: (/home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/lib/../lib/libuikit-editor.so: Undefined symbol "_ZTV6UiEdit")
 [PluginManager] Can't load plugin: /home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/bin/plugins/libshadertools.so With error: Cannot load library /home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/bin/plugins/libshadertools.so: (/home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/lib/../lib/libuikit-editor.so: Undefined symbol "_ZTV6UiEdit")
 [PluginManager] Can't load plugin: /home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/bin/plugins/libpipelinetools.so With error: Cannot load library /home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/bin/plugins/libpipelinetools.so: (/home/brad/git/thunder-build/install-root/sdk/2024.2/freebsd/x86/lib/../lib/libuikit-editor.so: Undefined symbol "_ZTV6UiEdit")

We have a winner!!! The uikit one up top is a bug but not a major one right now.

[bedwardly-down]

Is that Qt though?

[eprikazchikov]

No. Will check it tomorrow, It's too late for me now =) need to sleep.

[eprikazchikov]

Have cc2ef43 solved the boot up issue?

[bedwardly-down]

Have cc2ef43 solved the boot up issue?

See here: https://github.com/thunder-engine/thunder/pull/791 .

[bedwardly-down]

There's still some bugs that need to be ironed out but I can't believe WorldEditor is running natively. The performance is a bit bad at the moment but that could be related to https://github.com/thunder-engine/thunder/issues/789 . With the debug build, I've attached the output. Like suggested by the FreeBSD developer above, it looks like at least one of the shaders may need some tweaking.

world-editor-first-flight.txt

[eprikazchikov]

I guess this issue can be closed. For shader compilation errors I'm suggesting to create a new one.

[bedwardly-down]

I guess this issue can be closed. For shader compilation errors I'm suggesting to create a new one.

Definitely closed and noted.