Segfault in igxelpicd64.dll if no SwapBuffers was called (Windows, OpenGL)

[gr3yknigh1]

Hello there! I'm not sure if this is the right board for this, so I apologize in advance if it is not.

I'm working on an OpenGL Windows application and my program is crashing in the igxelpicd64.dll  driver thread when I don't call the SwapBuffers function after calling the glClear and glClearColor functions in the main loop. The crash occurs after a certain amount of time has passed, not immediately, which is why I believe there might be some kind of race condition at play.

Here is some pseudocode. If you would like, I can you with provide more debug information and the full source code or pre-compiled executable files of my application. You will need MSVC and CMake to build the project.

#include "my_opengl_loader_which_definitly_not_related_to_segfault.h"
#include "my_window_library_which_sure_not_related_to_issue.h"

int
main(void)
{
  // Window creation
  // Render context initialization
  // Loading functions from opengl32.dll

  while (1) {
    glClear(...);
    glClearColor(0, 0, 0, 1);

#if !defined(WANT_SEGFAULT_IN_IGXELPICDDLL)
    SwapBuffers(GlobalDeviceContext);
#endif
  }
}

Here is my software and hardware information:

Operating System: Microsoft Windows 11 Home 10.0.22631
IGCC Version: 1.100.5635.0
Language: en-US
Physical Memory: 15.73 GB
Current Resolution: 2880x1800

Processor: 12th Gen Intel(R) Core(TM) i5-12500H
Processor Speed: 2500 MHz
GFX Driver Name: Intel® Iris® Xe Graphics
Shader Version: 6.6
OpenCL* Version: 3.0
* Microsoft DirectX* *
Runtime Version: 12
Hardware-Supported Version: 12
Vendor ID: 8086
Device ID: 46A6
Device Revision: 0C
GFX Driver Version: 31.0.101.4502
Dedicated RAM: 128 MB
Shared RAM: 8 GB
Max Supported Displays: 4
GFX Vulcan: 1.3.250
GFX GOP: 21.0.1046

* Digital Display 1 *

Display Name: Built-In Display
Display Type: Digital
Serial Number: -
DDC2 Protocol: Supported
Gamma: 2.2
Connector Type: DisplayPort

Maximum Image Size
Horizontal - 11.81 inches
Vertical - 7.48 inches

Supported Modes
2880 x 1800 (60p Hz)
2880 x 1800 (90p Hz)

[VonM_Intel]

Hi, gr3yknigh1.

Thank you for posting in our Community.

It looks like you're dealing with an interesting issue, and I think you're on the right track with your analysis. Based on your description, it's possible that the crash is related to how OpenGL handles the buffer swap in relation to your render context, especially if "SwapBuffers" is not being called. It might indeed be a timing issue, which could be a sign of a race condition or an issue with synchronization between the CPU and GPU.

In the meantime, I'll need to conduct some additional research on this issue and will post an update in this thread as soon as I have more information. Regarding the full source code, feel free to share it along with any debug information or even a pre-compiled version. I'd be happy to take a closer look and assist with troubleshooting further.

Have a nice day!

Best regards,

Von M.

Intel Customer Support Technician

[gr3yknigh1]

Hello! Thank you for your response and your time.

Here are the full source code and two pre-compiled binaries: one that calls Swapbuffers and one that does not. I have also added some notes in the README.txt file.

Have a great day!

[VonM_Intel]

Hi, gr3yknigh1.

Thank you for your response and for providing the source code and the pre-compiled binaries. To assist you further and investigate this issue more effectively, could you please provide the following information:

1. What is the name of the OpenGL Windows application and the program where the crash occurred?
2. Are you the developer of this program, or is this a third-party application?
3. Please update the graphics driver to version 32.0.101.6297, as the version 31.0.101.4502 you mentioned is not the latest release. You can download the updated driver here: Intel® Arc™ & Iris® Xe Graphics - Windows
4. Was the application working fine before? If so, when did the issue first start occurring?
5. If the problem persists after updating the driver to version 32.0.101.6297, could you kindly provide the latest SSU logs for further analysis?

Looking forward to your response.

Best regards,

Von M.

Intel Customer Support Technician

[VonM_Intel]

Hi, gr3yknigh1.

I'm following up to check whether you have had the chance to review our prior correspondence. If you have, kindly acknowledge receipt and let me know if you need time to share the details I asked for. Please let me know about this information so we can identify the next steps that need to be taken to resolve this issue.

I will wait for your reply.

Best regards,

Von M.

Intel Customer Support Technician

[gr3yknigh1]

I apologize for the delay in responding. This week has been busy, and I also had difficulty logging into this forum using my credentials. There was some strange error at the login page.

Regarding your previous question:

1. A crash occurred in a separate thread of the igxelpicd64.dll Windows driver while my application was running.

2. As I explained in my initial question, I am developing a game engine based on OpenGL rendering.

3. I tried updating my drivers before with some Intel apps (probably called "Intel Driver & Support Assistant"), and also tried updating with an app from my laptop vendor (Lenovo). However, the issue still persisted (and I have reported it here after all the updates). I will try again this week and let you know the results.

4. In the past, Intel drivers have crashed in other cases, but it was due to my fault with the render context initialization. I didn't have enough knowledge to properly report the problems there. This time, I was able to reproduce and isolate the problem to a single line of code, so I decided to report it.

5. Of course! When I update all my graphics drivers, I will try to reproduce the issue.

Thank you for your time! Again, I apologize for the delay in my response. Have a great day!

Best regards, Ilya A.

[VonM_Intel]

Hi, gr3yknigh1.

I appreciate that. I completely understand how busy things can get.

It’s great that you were able to isolate the problem to a specific line of code. That’s a huge step forward in troubleshooting. Regarding the crash in the igxelpicd64.dll driver, it sounds like you’ve already made good progress with driver updates, and I think revisiting them after your next round of updates is a good plan.  

Once you've had the opportunity to reproduce the issue, please feel free to update us along with your latest SSU logs for further analysis.

Thank you again for keeping us in the loop.

Best regards,

Von M.

Intel Customer Support Technician

[VonM_Intel]

Hi, gr3yknigh1.

Thank you for your patience. I have reviewed the thread carefully and understand that you are developing a game engine based on OpenGL rendering. Please note that we have a dedicated forum for these specific issues, so I will be moving this thread to the "Developing Games on Intel Graphics" section to ensure it gets addressed more promptly and effectively.

Best regards,

Von M.

Intel Customer Support Technician

[karen_intel]

Hey @gr3yknigh1 Welcome to the Intel Game Dev Support Forum!
I will be assisting you in this case. Please have a look at our readme post

For debug purposes and to confirm the issue, can you share the executable or the small code to reproduce on our end?

The smaller, the better

Also, is your game engine in early development stage? If not, how many average users does it have?

Thanks, looking forward to hear from you

Karen

[gr3yknigh1]

Hello! I have already shared the executables in this post. Please check the `README.txt` file, where I have explained where the code is located. It's quite small, but if is't still too large, I can try to extract a smaller example later. However, the smallest code snippet is in the initial post. All sources are located in the `codebase` folder, and you can build all using `build_without_conan.bat`. The minimal dependencies are MSVC and CMake.

This project is a private game engine that currently has only one user (me). But it's not only about game engine development. It's confusing, why this thread was moved to gamedev, because issue seems to be related to the graphics driver crashing due to a race condition.

Ilya. A

[karen_intel]

Thanks @gr3yknigh1 . Allow me to do some debug with the package you shared.

The reason why it was moved is because anything that has to do with Development on Intel Graphics has to be handled in this forum, we're the specialists on development, which cannot be found in the regular Graphics Support Forums

I'll be back with my results, thanks for the fast response.

Karen

[Diner]

Found 2 use cases:

Faced the same problem, but for me it was not a timing issue, just an initialization issue.

This happened because I'm porting an app from Legacy to Core OpenGL.

When you look at the "problem" code below and would set a breakpoint on the markers, here are the values of "PosAttrLoc": 

At marker #1: PosAttrLoc was 0

At marker #2: PosAttrLoc was -1 (bug here)

This was my "problem" code:

GLint PosAttrLoc = -1;

void SetupModel()

{
glGenVertexArrays(1, &MyMesh->VAO);
glBindVertexArray(MyMesh->VAO);

// ..

glVertexAttribPointer(PosAttrLoc, 3, GL_FLOAT, GL_FALSE, stride, Offset(PositionNormalUV0, Position[0])); // <-- marker #2: READ
glEnableVertexAttribArray(PosAttrLoc);

// ..

}

void CreateProgram()

{

// ..

MyProgram = glCreateProgram();

// ..
PosAttrLoc = glGetAttribLocation(MyProgram "aPosition"); // <-- marker #1: SET

// ..

}

void Render()

{
glUseProgram(ProgramSkinned);

// .. setup uniform and stuff

glVertexAttribPointer(PosAttrLoc, 3, GL_FLOAT, GL_FALSE, stride, Offset(PositionNormalUV0, Position[0]));
glEnableVertexAttribArray(PosAttrLoc);

 glDrawElements(GL_TRIANGLES, TriangleCount * 3, GL_UNSIGNED_INT, TriangleData);
}

int main()

{

// ..

SetupModel();

CreateProgram();

// ..

while (..)

{

  Render();

  // Swap buffers and poll events
  glfwSwapBuffers(window);
  glfwPollEvents();
}

}

Solution:

In hindsight it was a kind of a "got-ya"-issue..

At marker #1 and marker #2 I expected "PosAttrLoc" to be 0, so my model was setting up the Vertex Attributes with all -1 locations.

For me the crash of igxelpicd64.dll happened due to bad initialization (kind of weird that it the whole driver crashes because of this, maybe a driver fix would be nice that just throws some GL_ERROR instead, if possible).

@gr3yknigh1 Maybe you have something similar? (I haven't checked your code)

My first step would be to check all attribute locations and uniform locations after that check all the buffers and buffer sizes for your VAOs.

So the crash was caused by attribute location == -1.  

Fixed code:

int main()

{

// ..

// Swapped 2 initialization methods:

CreateProgram(); // Sets 'PosAttrLoc' (will set to '0')

SetupModel();      // Reads 'PosAttrLoc'

// ..

}

DLL Version: 31.0.101.4255

Happy New Year and kind regards,

Diner

Edit: Found a 2nd use case:

There are some serious issues with the driver..

// Initialization code:

static void CreateContainerColored(unsigned int& VBO, unsigned int& VAO, unsigned int& EBO)
{
// set up vertex data (and buffer(s)) and configure vertex attributes
// ------------------------------------------------------------------
float vertices[] = {
// positions // colors
0.25f, 0.25f, 0.0f, 1.0f, 0.0f, 0.0f,
0.25f, -0.25f, 0.0f, 0.0f, 1.0f, 0.0f,
-0.25f, -0.25f, 0.0f, 0.0f, 0.0f, 1.0f,
-0.25f, 0.25f, 0.0f, 1.0f, 1.0f, 0.0f,
};
unsigned int indices[] = {
0, 1, 3, // first triangle
1, 2, 3 // second triangle
};

glGenVertexArrays(1, &VAO);
glGenBuffers(1, &VBO);
glGenBuffers(1, &EBO);

glBindVertexArray(VAO);

glBindBuffer(GL_ARRAY_BUFFER, VBO);
glBufferData(GL_ARRAY_BUFFER, sizeof(vertices), vertices, GL_STATIC_DRAW);

glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, EBO);
glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(indices), indices, GL_STATIC_DRAW);

// position attribute
glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 6 * sizeof(float), (void*)0);
glEnableVertexAttribArray(0);
// color attribute
glVertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE, 6 * sizeof(float), (void*)(3 * sizeof(float)));
glEnableVertexAttribArray(1);

// marker #B: please note that we did NOT set 'aTexCoord', which is probably not the problem perse..

// but the stride is incorrect compared to the shader: 

// shader wants: vec3 + vec3 + vec2 == 8
// code supplies: 6 * sizeof(float)
}

// My Vertex Shader:

#version 330 core

layout (location = 0) in vec3 aPos;

layout (location = 1) in vec3 aColor;

layout (location = 2) in vec2 aTexCoord; // <-- marker #A

out vec3 ourColor;

void main()

{

gl_Position = vec4(aPos, 1.0);

ourColor = aColor;

}

Solution:

marker #A: This one is NOT set in our 'glVertexAttribPointer'. This causes a crash of igxelpicd64.dll.

marker #B: Here I've should have set the correct stride and 'aTexCoord'.

When I comment 'aTexCoord' out (so my stride is correct again) it no longer crashes (since stride is correct again).

So the crash was caused by shader stride != code stride.

[gr3yknigh1]

Hello!

@Diner No. Please, read my initial post.

In my repro code, there are is no draw calls, no vertex prep code, and no shaders. Only glClearColor and glClear. There are no error codes was from OpenGL or Windows.

I have provided a minimal pseudo-example, and full source code (which is not that big).

Best regards,

Ilya