Realsense_viewer massive memory leak and crash with Intel graphics #10209
Comments
|
Hi @noirflux I have seen a memory leak occur in the Viewer before as a consequence of the GLSL feature being enabled (it is enabled by default), as described in #8110 (comment) Could you try disabling the two GLSL options in the Viewer's settings interface using the instructions at #8110 (comment) to see whether this resolves your memory leak, please? |
|
Yes, turning off the GLSL option stops the memory leak. Leaving just the GLSL rendering option on, still no memory leak. Turning on just the GLSL processing option may cause a memory leak, but it is very slow in comparison to them both being on. Interestingly, when I turned off both options after first running with them both on, and 8GB of memory had been consumed, the memory was freed when I clicked OK in that dialogue box. So this is an obvious repeatable bug. |
|
Problems such as memory leaks or disappearing point cloud when GLSL is enabled in the Viewer is a repeatable issue and there is an existing official Intel bug report about it. There are no further details that I can provide regarding a timetable for a fix though. |
|
Hi @noirflux Do you require further assistance with this case, please? Thanks! |
|
Where is that bug report? And where are the official Intel bug reports in general? Usually in release notes there is a "known bugs" section, but I don't see that here, just fixed bugs. That's the kind of thing that can help people wasting time chasing down things that are already known. Searching here for open bugs yields only 5 issues and I don't see it there (and I find it hard to believe there are only 5 known bugs not fixed yet). |
|
Intel bug reports are internal documents that are not accessible to the public. You can though get a sense of some of the currently active RealSense related issues that have been officially logged as feature requests or possible bugs by looking at the list of public cases on this librealsense GitHub with an Enhancement label. Left-click on the blue Enhancement label below to view the list. |
|
Thanks for that info. Though in looking though that list, I do have to take issue with labeling things like fixing a fatal exception as an "enhancement" rather than a "bug"! |
|
Because GitHub issues associated with an internal report are kept open whilst that report is active, the Enhancement tag acts as a clear at-a-glance reminder to me not to close that case. When an internal report is concluded, the Enhancement tag is removed from the GitHub issue paired to it so that issue can be considered for closure. |
|
Hi @noirflux Do you require further assistance with this case, please? Thanks! |
|
Case closed due to no further comments received. |
Issue Description
As soon as I start the depth stream in the viewer, RAM memory use starts going up. When RAM is maxed (16GB in a few minutes) the viewer framerate and overall Windows responsiveness starts dropping as paging memory starts getting used. This happens much faster with the 3D display than 2D, but it still happens in 2D. Eventually what usually happens is Windows then blue screens, sometimes viewer just crashes.
I have been able to duplicate this using the standalone viewer going back to 2.39, have not tried earlier as not sure firmware is compatible. This happens on multiple PCs running different versions of Win 10.
An interesting thing is that it appears to be related to running on the integrated Intel graphics; on the Alienware, when I explicitly set viewer to run on the GTX1060 using nVidia Control Panel, the problem stopped. It also does not happen on non-laptop PCs where I am directly using nVidia cards.
I run all sorts of graphics apps on these laptops, and this is the only program doing this. Even programs using the depth stream via the SDK work fine - this is a viewer-only problem as far as I have seen.
My suspicion is that it is coming from the display portion of the viewer, since SDK programs work fine, and switching to 3D from 2D in the viewer accelerates the memory use.
The text was updated successfully, but these errors were encountered: