OpenGL Windows drivers for Intel HD 630 leaking GPU memory when using shared contexts

[yosoymin]

I've found an issue for Intel OpenGL drivers for Windows since version 27.20.100.8783 tested in a Intel HD 630. The symptom is that the GPU memory usage starts increasing until the whole system crash.

The way to reproduce this memory leak is to create a shared context, then create some textures on that shared context (should be more than one texture), then change to the main OpenGL context and destroy the previously created textures. If you do this process in a loop, you will see that the GPU memory grows very fast.

I've done a simple program in github that reproduce this, so you can try and reproduce: https://github.com/yosoymin/InitGL/tree/intel_shared_context_leak

This program runs ok in older versions of Intel drivers (27.20.100.8681 tested in a Intel HD 655 and HD 630) and aslo in Linux or with other vendor drivers.

Maybe this can be related to this issue: https://community.intel.com/t5/Graphics/BUG-dwm-exe-uses-memory-leakage-with-Intel-HD-Graphics-630/td-p/1222297

Hope this helps you to fix this problem.

Thanks

[HKlum]

@RonaldM_Intel 

Also when will this issue be fixed: https://bugs.chromium.org/p/chromium/issues/detail?id=1107403

Does Intel even have a bug tracker for that issue? Intel drivers crash when using decode swap chains, this issue is present now for 2 years. And root cause of a lot of issues in several applications.

[DeividA_Intel]

Hello yosoymin,  

Thank you for posting on the Intel® communities.   

In order to have a better view of this issue, please provide the following:  

1. Run the Intel® System Support Utility (Intel® SSU) to gather more details about the system.  

· Download the Intel® SSU and save the application on your computer : https://downloadcenter.intel.com/download/25293/Intel-System-Support-Utility-for-Windows-

· Open the application, check the "Everything" checkbox, and click "Scan" to see the system and device information. The Intel® SSU defaults to the "Summary View" on the output screen following the scan. Click the menu where it says "Summary" to change to "Detailed View".  

· To save your scan, click Next and click Save.  

2. Provide the Report for Intel® Graphics Drivers: 

- https://www.intel.com/content/www/us/en/support/articles/000005848/graphics.html 

Regards,  

Deivid A. 

Intel Customer Support Technician 

[HKlum]

This was a direct bug report with a proof of concept. You dont need the data of the "Intel support utility".

[yosoymin]

Hi Deivid,

here you are the report required

[DeividA_Intel]

Hello yosoymin, 

Based on the report looks like you are using a driver version "27.20.100.9466" (which is different from the one reported) and I would like to know if you experience the same issue in both versions (27.20.100.8783 and 27.20.100.9466). Also, I would appreciate it if you prove the Graphics report, this would help to reproduce the issue and find a possible solution.

- Report for Intel® Graphics Drivers: 

https://www.intel.com/content/www/us/en/support/articles/000005848/graphics.html 

Regards,  

Deivid A. 

Intel Customer Support Technician 

[yosoymin]

Hi Deivid,

the issue affects to all drivers since version 27.20.100.8783. This is the first version were the issue appears, so it affects to version 27.20.100.8783, 27.20.100.8853, 27.20.100.8935, 27.20.100.9030, 27.20.100.9079, 27.20.100.9126, 27.20.100.9168, 27.20.100.9316 and 27.20.100.9466.

In the previous version 27.20.100.8681 the program I've supplied works properly.

The issue is really easy to reproduce, you only need to download the github repository, build the project with cmake and Visual Studio or another C++ compiler you want, and then run the resultant executable.  You will see the memory grows very fast, and it shouldn't. The code it's only a single file main.cpp and 2 dependencies (glad and glfw), everything is setup and ready to compile. If you want I can provide an executable, but I think is more secure to be able to compile directly from the code.

I've tried the Report for Intel® Graphics Drivers, but it seems to have another issue because it says that can't generate the report. I'm uploading some screenshots, just if you want to check some system info.

Thanks

   

[DeividA_Intel]

Hello yosoymin, 

Thank you for the information provided 

I will proceed to check the issue internally and post back soon with more details. 

Best regards, 

Deivid A.  

Intel Customer Support Technician 

[DeividA_Intel]

Hello yosoymin, 

I would like to thank you for reporting this issue with us here, however, since the issue is not occurring on a commercially available application the best place to report it is the Intel® Developer Zone, so an Intel Developer can step in and review the situation first. If it's found to be fine and rather a driver issue then it may be promoted to the driver developer team.

- Main web site: Software.intel.com

- Intel® Developer Zone forum: https://software.intel.com/en-us/forum

Best regards, 

Deivid A.  

Intel Customer Support Technician 

[AlejandroGR]

Why do you say this is not not occurring in a comercially available application?😅 This bug is very easy to reproduce and uses a feature that is very commonly used by applications of all kinds (shared contexts).

[HKlum]

Erm what do you expect? This is Intel. Except to thank someone for a bug report maybe even pay them like other companies do, they try to delay, deny, ignore for years. In some cases even risk security exploits to be announced after a dead line, and then start to look into it. This is Intel.

[HKlum]

I also had crashes in Chrome btw in the past months a lot, maybe even for a year or so. It happens often when using WebGL elements for example Google maps. It just crashes 10 minutes ago when I was using Google maps and I got this output in chrome://gpu

Log Messages

• GpuProcessHost: The info collection GPU process exited normally. Everything is okay.
• [1252:3192:0428/080154.625⚠️ipc_message_attachment_set.cc(49)] : MessageAttachmentSet destroyed with unconsumed attachments: 0/1
• [1252:3192:0428/080618.174:ERROR:shared_image_manager.cc(214)] : SharedImageManager::ProduceSkia: Trying to Produce a Skia representation from a non-existent mailbox.
• [1252:3192:0428/080618.174:ERROR:shared_image_manager.cc(214)] : SharedImageManager::ProduceSkia: Trying to Produce a Skia representation from a non-existent mailbox.
• [1252:3192:0428/192445.862:ERROR:shared_image_manager.cc(214)] : SharedImageManager::ProduceSkia: Trying to Produce a Skia representation from a non-existent mailbox.
• [1252:3192:0428/194041.376:ERROR:angle_platform_impl.cc(43)] : Renderer11.cpp:2135 (testDeviceLost): The D3D11 device was removed, HRESULT: 0x887A0006
• [1252:3192:0428/194041.376:ERROR:shared_context_state.cc(826)] : SharedContextState context lost via ARB/EXT_robustness. Reset status = GL_UNKNOWN_CONTEXT_RESET_KHR
• GpuProcessHost: The GPU process crashed!
• GpuProcessHost: The info collection GPU process exited normally. Everything is okay.

Wonder if this has something to do with this bug now... @yosoymin what do you think? Sounds familiar?

[DeividA_Intel]

Hello, 

I just want to let you know that for software development or related issue/reports the Intel® Developer Zone is a better place to post it. An Intel Developer can step in and review the code first. If it's found to be ok and rather a driver issue then it may be promoted to the driver developer team. this support is meant mostly for hardware, and this is more for software developers.

Best regards, 

Deivid A.  

Intel Customer Support Technician 

[HKlum]

@DeividA_Intel If you look into here:

https://community.intel.com/t5/Developing-Games-Graphics-on/efficient-access-pattern-for-different-dx11-memory-types/td-p/1271557

no one from Intel seems to have looked into the dev boards since months or even years.

[RonaldM_Intel]

I added all the information provided in this thread to the existing bug ID 22012524606 i.e. the one for the issue of https://community.intel.com/t5/Graphics/BUG-dwm-exe-uses-memory-leakage-with-Intel-HD-Graphics-630/m-p/1274384#M96313

If the devs find it is a separate bug then it will handled as such internally, otherwise it can prove to be a useful data point for our ongoing investigation on the dwm.exe memory leak.

Thanks for providing this information.

Best Regards,

Ronald M.

for our devs to consider while they work on