Bindless textures functions throw seg fault [SOLVED]

OpenGL
1

What’s up.
I’ve got a new laptop and I was installing arch linux on it so that it is exactly as my pc. Now I cloned my opengl project where I use bindless textures and when I try to run it it throws a seg fault in the line of this function:

glGetTextureHandleARB()

This one is the first arb function that appears in the program lifetime.
I’ve been trying to solve this problem since yesterday and I made sure that:
My opengl context is set properly,
Glew is initialized properly,
Before calling that function, the pointer to that function is valid,
It seems like I have bindless textures available:

[coolfede97@coolfede97 ~]$ glxinfo | grep -i "GL_ARB_bindless_texture"

    GL_ARB_bindless_texture, GL_ARB_blend_func_extended, 
    GL_ARB_bindless_texture, GL_ARB_blend_func_extended,

The texture I pass as argument to that function is valid

I’ve got a intel gpu:

[coolfede97@coolfede97 ~]$ lspci | grep -i --color 'vga\|3d\|2d'   
00:02.0 VGA compatible controller: Intel Corporation Iris Plus Graphics G1 (Ice Lake) (rev 07)

and I use mesa:

[coolfede97@coolfede97 ~]$ pacman -Q mesa
mesa 1:25.3.3-2

I tried debugging with gdb, and it seems like the seg fault occurs when a function with an invalid pointer is called (which is strange since

 if (glGexTexutreHandleARB == nullptr)

returns false).

Here is the gdb output:

[New Thread 0x7fffcffff6c0 (LWP 9743)]
[New Thread 0x7fffcf7fe6c0 (LWP 9744)]
Buffer of textures 2D: 1
Texture2D at path: /home/coolfede97/coding/RuamEngine/RuamEngine/assets/sprites/defaultSprite.png was loaded succesfully
About to call glGetTextureHandleARB

Thread 1 "RuamEngine" received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007fffe1339ed1 in ?? () from /usr/lib/libgallium-25.3.3-arch1.2.so
#2  0x000055555558b35f in RuamEngine::Renderer::RegisterTexture (
    texture=std::shared_ptr<RuamEngine::Texture> (use count 2, weak count 0) = {...})
    at /home/coolfede97/coding/RuamEngine/RuamEngine/RuamCore/Rendering/Renderer.cpp:224
#3  0x0000555555593d5e in RuamEngine::ResourceManager::RegisterTextureInRenderer (
    texture=std::shared_ptr<RuamEngine::Texture> (use count 2, weak count 0) = {...})
    at /home/coolfede97/coding/RuamEngine/RuamEngine/RuamCore/Rendering/ResourceManager.cpp:161
#4  RuamEngine::ResourceManager::LoadTexture<RuamEngine::Texture2D> (relativePath="assets/sprites/defaultSprite.png")
    at /home/coolfede97/coding/RuamEngine/RuamEngine/RuamCore/Rendering/ResourceManager.h:35
#5  0x0000555555590dde in RuamEngine::ResourceManager::Init () at /usr/include/c++/15.2.1/bits/basic_string.tcc:248
#6  0x000055555558c6a5 in RuamEngine::Renderer::Init ()
    at /home/coolfede97/coding/RuamEngine/RuamEngine/RuamCore/Rendering/Renderer.cpp:72
2

This won’t work on X11. glXGetProcAddress returns a (non-null) pointer to a stub function which dispatches to the actual function based upon which driver is responsible for the context. glXGetProcAddress always returns the same pointer for a given function regardless of the context. If the function isn’t implemented by the driver corresponding to the current context, you’ll end up with the stub function calling a null function pointer.

This differs from Windows, where wglGetProcAddress can return different pointers for the same function but on different screens. The pointer typically points directly into the display driver, so if you’re writing an application which can open multiple windows potentially on different screens (which could be using different GPUs), for each extension function you have to call wglGetProcAddress for each screen and store all of the pointers, each associated with the correct screen.

3

Thanks for the reply.
I managed to make it work without changing any code.
I did via zinc. My understanding of it is that mesa and intel have an incomplete implementation of the extension of bindless textures. As a result, although my gpu is capable of using them, mesa didn’t have an implementation for it (actually idk if this is technically correct, that’s like my little brain’s interpretation).
However, with zinc (I understand it as a translator from OpenGL to Vulkan), it works since Vulkan and Intel get on with well in the sense of not having partial implementations for OpenGL. Therefore, it’s like all my code of OpenGL is being translated to Vulkan so that the implementations of bindless textures work well (again, I’m sure if all I’m saying is right).

Nevertheless, the important thing is that I solved it by running my program with:

MESA_LOADER_DRIVER_OVERRIDE=zink ./NameOfMyProgram

Again, thanks for your answer. Your reply taught a bunch of things