Segmentation fault with nullptr instruction in AbstractShaderProgram at Cross-Compile #635
Comments
Desperado17
changed the title
Desperado17
changed the title
|
Hello, the backtrace is a bit confusing, it shows In general, such nasty null pointer access happens only when attempting to access GL functionality that isn't actually present in the driver. In this case it might be that Can you post the engine startup log it prints to the console? It should show the GL version and driver it detected, and a list of opt-in extensions it found and uses. Based on that I should be better able to figure out what's going on and how to prevent this from happening. Another possibility when this could happen would be with some multithreading going on and a GL context attempted to be used on a thread it wasn't created on, or with some particularly interesting shared + static library setup, but I don't think either of that is the case here. Thank you! (By the way, the 2020.06 tag is rather old -- unfortunately I didn't have the capacity to bring the roadmap to a releaseable state since then so there's no newer tagged version, but the |
|
Ok, some more info: It's a nullptr access to an uninitialized function pointer to an OpenGL function who as I can tell should be initialized here: The nullptr are for all the core functions. For example flextGL.ProgramUniform1ui = reinterpret_cast<void(APIENTRY*)(GLuint, GLint, GLuint)>(loader.load("glProgramUniform1ui")); yields a nullptr on my platform. As far as I can tell OpenGLFunctionLoader uses eglGetProcAddress This function returns nullptr for core functions on my platform. |
|
Just to clarify -- the function will return What I'm trying to get at is what's actually advertised as supported by the driver, which is shown in the startup log right after you run the application and before it crashes. Can you get me that? It'd be something like this and the list of extensions and workarounds is what I need: Renderer: NVIDIA GeForce RTX 3050 Laptop GPU/PCIe/SSE2 by NVIDIA Corporation
OpenGL version: OpenGL ES 3.2 NVIDIA 535.113.01
Using optional features:
GL_EXT_texture_filter_anisotropic
GL_EXT_robustness
...Thank you! |
|
I have to come back for the log tomorrow when I'm back at work. But some more info: flextGL.ProgramUniform1ui = reinterpret_cast<void(APIENTRY*)(GLuint, GLint, GLuint)>(loader.load("glProgramUniform1ui")); yields nullptr but flextGL.ProgramUniform1uiEXT = reinterpret_cast<void(APIENTRY*)(GLuint, GLint, GLuint)>(loader.load("glProgramUniform1uiEXT")); returns a fully working pointer that, according to gdb, points to the very available glProgramUniform1ui . The system with this driver supports at least GLES 3.1, I know that from other applications. As far as I know in EGL 1.4 eglGetProcAddress does not guarantee pointers for core functions. |
|
Awesome, that's good to know, so there's at least some possible path forward.
Oh, that's not great. I hope I won't need to add a workaround with Looking forward to the log. |
|
Do I need to set special environment variables for the log or so? My short-term solution is to try load the ext version of a function if the core version is not returned. Don't know if this can still yield nullptr access for some stuff, I'm not seeing check in the accessing functions. Edit: In EGL 1.5 pointers for core should be guaranteed. |
It's printed by default unless suppressed by some log redirection, so assuming a Linux box, it should be there always. On Android it's thrown into
A quick patch to achieve what you need would be this: diff --git a/src/Magnum/GL/Implementation/ShaderProgramState.cpp b/src/Magnum/GL/Implementation/ShaderProgramState.cpp
index 8a87a8b59..d49b45e95 100644
--- a/src/Magnum/GL/Implementation/ShaderProgramState.cpp
+++ b/src/Magnum/GL/Implementation/ShaderProgramState.cpp
@@ -93,7 +93,7 @@ ShaderProgramState::ShaderProgramState(Context& context, Containers::StaticArray
#ifndef MAGNUM_TARGET_GLES
if(context.isExtensionSupported<Extensions::ARB::separate_shader_objects>())
#else
- if(context.isVersionSupported(Version::GLES310))
+ if(false && context.isVersionSupported(Version::GLES310))
#endif
{
#ifndef MAGNUM_TARGET_GLES
If we don't find any better solution, then I turn this into a driver-specific workaround that gets enabled automatically. But I hope we find something better :)
There's none for perf reasons. For core functionality (like shaders, buffers, textures) it internally picks a variant that should be there, and for APIs that aren't guaranteed to be present (say, compute shaders), it's up to the application to do an extension / version check upfront. |
|
Hmm I cannot find your logging. Can you tell me which function call in magnum supposedly triggers it? I copied the weston output if that helps: 23:00:00.478 [Warn] [user] weston@tty1: [23:00:00.474] EGL version: 1.4 |
|
It's printed by Or just show me how you initialize the application, I'll point you to where it should get printed. Alternatively you could build the |
|
Platform::GLContext ctx{argc, argv}; Should this be enough to trigger the code? |
|
Yes. Do you get anything printed if you |
|
Ok, so I added the Platform::GLContext ctx{argc, argv}; directly after the eglMakeCurrent of the OpenGL context I create myself. No output. The I added the header and Debug{} << "hello?"; no output Do I need to set up something else? Is it generally possible to combine Magnum with an existing EGContext? Only magnum-gl-info worked: |
|
Thank you. The I have no idea what's going on. This is a Linux system, not Android or something specific, right? Can you try to reduce your application to a small self-contained repro case that compiles & runs (and crashes) on your end, and prints no output? I suspect there's something else going on that flew under the radar for me so far, and I can't really help if I can't see any code. |
|
Does this print to stdout or stderr? |
|
Standard output, |
|
Just for check: Do you see a problem with any of these cmake configure parameters? -DWITH_GL=1 -DTARGET_GLES=ON -DTARGET_GLES2=OFF -DTARGET_GLES3=ON |
|
Everything looks fine. Can you show me some minimal code that reproduces the problem? I still know only very little about the setup you have. |
|
Working on it. Meanwhile, another problem has arised: It seems that some of the GL related flags like WITH_GL, TARGET_GLES, TARGET_GLES3 or WITH_EGLCONTEXT cause header conflicts with Qt6: Is there something special one has to do to either Magnum or Qt so the two work together? |
|
Not sure about Qt 6 yet, but a setup that worked for Qt 5 is here -- one has to ensure a certain order of includes, and convince Qt to use external GL definitions: https://github.com/mosra/magnum-bootstrap/blob/ea8e1b0b449c3e67dee337e46d71c1735a4b7f56/src/MyApplication.cpp#L1-L23 |
|
This is the current setup. Still fails with undefined symbol in the include hierarchy of |
|
Alright, I think I know what's going on -- Qt's GL headers are the big, desktop version, while Magnum built for GLES uses the ES headers. Not really sure if anything about this can be done on Qt's side (if it can be persuaded to expose the GLES API set instead) but I managed to fix the build by adding #define __glext_h_
typedef double GLdouble;at the top. The (The bootstrap project is updated with this info as of mosra/magnum-bootstrap@195e713.) |
|
Closing as there doesn't seem to be anything actionable left to do. I think the original problem was that |
With magnum and corrade 2020.06
Greetings,
when cross-compiling magnum/corrade for GLES and Aarch64, the program suddenly runs into a nullptr instruction:
#0 0x0000000000000000 in ?? ()
#1 0x0000007ff7c04efc in Magnum::GL::AbstractShaderProgram::setUniform (this=this@entry=0x7fffff87d8, location=2, values=...) at ext-corrade-dev/1/workspace/usr/include/Corrade/Containers/Pointer.h:217
#2 0x0000007ff7ae9630 in Magnum::GL::AbstractShaderProgram::setUniform (value=, location=, this=0x7fffff87d8)
at ext-corrade-dev/1/workspace/usr/include/Corrade/Containers/ArrayView.h:195
#3 Magnum::Shaders::Flat<2u>::Flat (this=0x7fffff87d8, flags=...) at ext-magnum/1/workspace/ext.magnum/src/Magnum/Shaders/Flat.cpp:140
Flat.cpp 136:
#ifndef MAGNUM_TARGET_GLES
if(!GL::Context::current().isExtensionSupportedGL::Extensions::ARB::shading_language_420pack(version))
#endif
{
if(flags & Flag::Textured) setUniform(uniformLocation("textureData"), TextureUnit); <---
}
AbstractShaderProgram.cpp:640:
void AbstractShaderProgram::setUniform(const Int location, const Containers::ArrayView values) {
(this->*Context::current().state().shaderProgram->uniform1ivImplementation)(location, values.size(), values);
}
The error is 100% reproducible. Is it possible that uniform1ivImplementation is corrupted at some point?
Regards
The text was updated successfully, but these errors were encountered: