I've been noticing a memory leak issue when keeping the Unraid dashboard open in Google Chrome. Over time, the RAM usage for the Chrome tab running Unraid steadily climbs higher and higher until it reaches around 5GB, at which point the tab crashes: "aww snap" screen. This happens even when the dashboard is simply open and idle, without any interaction.

I'm currently running:

 

Unraid Version: 6.12.13
Chrome Version: 132.0.6834.159 (Official Build) (64-bit)

I’ve also seen reports from others experiencing similar behavior in Unraid 7, so this might not be limited to Unraid 6.

 

Installed Plugins & Versions
Unassigned Devices (2025.02.12)
Unassigned Devices Preclear (2025.02.12)
Appdata Backup (2024.11.21)
Community Applications (2025.01.28)
Dynamix System Statistics (2025.01.18)
Dynamix System Temperature (2024.07.10)
GPU Statistics (2024.12.14)
Intel GPU TOP (2024.12.16)
Tailscale (2024.12.06)
Theme Engine (2023.01.17)
User Scripts (2024.12.19)

Has Anyone Else Experienced This? I’m wondering if this is a known issue, and if there are any potential fixes or workarounds available. It seems to be happening even in Unraid 7, so I’m not sure if this is a Chrome-related issue, an Unraid UI bug, or something else.
 

Would appreciate any insights!

Upgrade to 6.12.15 or 7.0.0, there is a fix that may help with that.

ok, i'll try upgrading to 6.12.15 first. Will report back.

 

edit: unfortunately same issue happening on 6.12.15. My friend who is running 7 said he's seeing the same behaviour occasionally as well.

Edited February 23, 20251 yr by CheekyPanda

Since 6.12.x is no longer being developed, update to 7.0 and if you still see the same, please create a bug report.

On 2/24/2025 at 3:52 AM, JorgeB said:

Since 6.12.x is no longer being developed, update to 7.0 and if you still see the same, please create a bug report.

I upgraded to 7.0.1 and still having the same issue. I'll create a bug report.

Might be an extension you have, I've never had an issue with chrome.

15 minutes ago, Kilrah said:

Might be an extension you have, I've never had an issue with chrome.

I agree. It could be related to Bitwarden. 

If you find that it's not Bitwarden, can you try hiding the graphs for cpu load and network and see if that eliminates the issue or makes it better.

 

I've been trying to replicate this, but thus far haven't been able to

6 hours ago, Squid said:

If you find that it's not Bitwarden, can you try hiding the graphs for cpu load and network and see if that eliminates the issue or makes it better.

 

I've been trying to replicate this, but thus far haven't been able to

Yes, closing those two graphs seems to prevent it from crashing. The Chrome RAM usages seems to have stabilized somewhere around 150MB.

16 hours ago, CheekyPanda said:

Yes, closing those two graphs seems to prevent it from crashing. The Chrome RAM usages seems to have stabilized somewhere around 150MB.

Not sure whether that's what I wanted to hear or not.

 

I managed to replicate this issue once when I started looking at it, and did "fix" it, but when I went back to stock (to confirm that the issue happened again), it didn't happen again (or on multiple future tries).

 

I believe that this is a memory leak caused by the library used to generate the graphs, (various reports online about this library, but they're all old and the changelog for the library says that the problem was long solved).  The real solution (if this is indeed the cause) is switching the graphs to be rendered by a different library, but unfortunately it's not a drop in replacement so not an easy fix to do at this point in time.

 

5 minutes ago, Squid said:

Not sure whether that's what I wanted to hear or not.

 

I managed to replicate this issue once when I started looking at it, and did "fix" it, but when I went back to stock (to confirm that the issue happened again), it didn't happen again (or on multiple future tries).

 

I believe that this is a memory leak caused by the library used to generate the graphs, (various reports online about this library, but they're all old and the changelog for the library says that the problem was long solved).  The real solution (if this is indeed the cause) is switching the graphs to be rendered by a different library, but unfortunately it's not a drop in replacement so not an easy fix to do at this point in time.

 

Ok, thanks for the info! So would this fix be on the Dynamix System Statistics plugin side, or with Unraid? Should I create a formal bug report? I'd love to see this issue get fixed, because I know other people have reported the same issue in other forums - including a personal friend of mine IRL.

Nothing to do with System Statistics.  

 

This has already been officially entered into an internal bug tracking system.

Great, thank you very much for your help! Hopefully a solution can be found.

22 hours ago, CheekyPanda said:

Great, thank you very much for your help! Hopefully a solution can be found.

Question:  Does the system you're using and leaving a chrome tab open to the dashboard go to sleep?  (ie: a laptop). Just found my MacBook w/Chrome had the tab hit 4.8G overnight, and it should have wound up sleeping.

6 minutes ago, Squid said:

Question:  Does the system you're using and leaving a chrome tab open to the dashboard go to sleep?  (ie: a laptop). Just found my MacBook w/Chrome had the tab hit 4.8G overnight, and it should have wound up sleeping.

It’s a desktop machine, I have the settings set so that it never goes to sleep. Just to provide some context, it’s Ubuntu desktop. Not sure if that matters. 
 

mine goes to around 4.8GB then crashes that chrome tab. 

 

On 3/20/2025 at 9:18 AM, CheekyPanda said:

mine goes to around 4.8GB then crashes that chrome tab. 

Nearly positive I've got it solved.  Managed to find a way to replicate it consistently.  At least, the way that I found to replicate it is handled, but I have a feeling that your cause might just be the same as mine just manifesting itself differently.  Fix should wind up in the next OS release.  But, since you've probably noticed that once the tab's memory usage does get that high, even after closing it, chrome etc it will tend to stay high and grow rapidly.

 

Your current fix is to either reboot the server or on the server.

rm /var/tmp/charts_data.tmp

 

Only temporary fix though until the OS update.

1 hour ago, Squid said:

 

Nearly positive I've got it solved.  Managed to find a way to replicate it consistently.  At least, the way that I found to replicate it is handled, but I have a feeling that your cause might just be the same as mine just manifesting itself differently.  Fix should wind up in the next OS release.  But, since you've probably noticed that once the tab's memory usage does get that high, even after closing it, chrome etc it will tend to stay high and grow rapidly.

 

Your current fix is to either reboot the server or on the server.

rm /var/tmp/charts_data.tmp

 

Only temporary fix though until the OS update.

I was hopeful, but unfortunately that doesn't seem to have solved it. I ran that command in the terminal and refreshed the tab. Things seemed to be ok for the first 10 minutes or so, but then the ram climbed. Currently sitting at 4.1GB.

You have to actually close the tab, delete the file and then go back.  Any tab open to the dashboard that when closes if one of the tabs is huge will immediately cause the same problem

2 hours ago, Squid said:

You have to actually close the tab, delete the file and then go back.  Any tab open to the dashboard that when closes if one of the tabs is huge will immediately cause the same problem

Ok. Now, I completely closed the tab, SSHd into my server, ran the command. Opened the dashboard tab back up, and still the chrome tab memory is going up, now at over 6GB.

Do you know if this was fixed in 7.1.2?

Just wanted to follow up on this thread, was this memory leak issue ever resolved? I'm still on 7.0.1.