DISCUSSION

Memory Leak in ModBors Monitoring Service

17 people are following

Just curious if you are aware that you have a memory leak in this service.  It starts with 36MB of memory used, once it has been running a day it has already consumed nearly 2GB of memory.  This left unchecked will consume most peoples available memory in a few days.

Same issue here, I was just cruising the forums and stumbled on this thread, I've been running the latest version of the PC Application and the Raspberry Pi image on my Pi 4B. I checked memory after seeing this and after a day my machine crept up to 3400 MB for the monitoring service. 

Specs:

Intel i9 9900k, 32GB Trident Z CL16 3200 DDR4, RTX 3060ti Gaming X Trio, MSI Z390 Mobo. 

Also, I am unable to run the HWINFO only version due to a conflict between HWINFO and Corsair's Commander Pro

I've now uploaded a version with a possible fix here.

Basically it's re-initializing both Open- And LibreHardwareMonitor every 30min to reset their memory usage and avoid those giant leaks. So actually more a workaround than a true fix but I guess it should work.

Would be nice if some of you could test that again.
If it solves the problem we will publish a new version of the app containing the fix for everyone.

Seraksab

I've now uploaded a version with a possible fix here.

Basically it's re-initializing both Open- And LibreHardwareMonitor every 30min to reset their memory usage and avoid those giant leaks. So actually more a workaround than a true fix but I guess it should work.

Would be nice if some of you could test that again.
If it solves the problem we will publish a new version of the app containing the fix for everyone.

I was actually just playing with a scheduled task to restart the service every hr. I'll download and give it a go.

I just ran the the patch and will check back in 30 minutes, thank you so much for your help and speedy response.

Still climbing for me after about 40 minutes for me

Same here. Gave it 35min and it's still climbing. Going to restart everything and test again

got to 370 MB and I manually restarted the service, dropped back to the starting ~17MB.

Tried to post a photo but it exceeds the limit, the service appears to be holding steady around 140-160MB. I do notice a second ModBros Monitoring Service that is sticking around 70-80MB. One Service is called Mobro - Monitoring Service and the other ModBros Monitoring Service. I'm happy the number isn't climbing. Stopping either Service kills beta7. 

Mine is up at ~750mb after a few hours.  Restarting the service got it back to ~30mb for me.

I take back my last comment,  came back a couple hours later and I was sitting at 750MB so for now I'll just remain a Patreon and forgive me, revert to my Aida64 Sensory Panel. I'd like an update when there's a resolution.  Thanks for all your help today

Hello !

I have the same problem, with an Nvidia 980 GTX card. After a few hours, the memory slowly rises.

Besides, I don't know if this has a relation, but the idle Raspberry display has a refresh every 5 seconds. Reinstallation of the latest versions (Raspberry and software), it's always the same.

PS : By the time I took the screenshot and post my comment, it exceeded 200MB.

 

c0293b4a-aa54-404d-9148-5ae007082039.jpg

Seraksab

I've now uploaded a version with a possible fix here.

Basically it's re-initializing both Open- And LibreHardwareMonitor every 30min to reset their memory usage and avoid those giant leaks. So actually more a workaround than a true fix but I guess it should work.

Would be nice if some of you could test that again.
If it solves the problem we will publish a new version of the app containing the fix for everyone.

I'll test your new version, I'll be back to tell you in a few hours.

 

No change on my side, the memory is gradually increasing.

0ad18f53-0e9a-4c94-aa80-fd1604e026b5.ee851716.jpg

Well damn :/
That's really a bit of a frustrating issue, as it would be soo much easier and quicker if I could just test this on my machine..

Could you guys maybe download and run the standalone versions of OpenHardwareMonitor and LibreHardwareMonitor besides MoBro for a bit to check if those also keep increasing in memory?

Just to check whether the leak is already in their code or maybe my code reading and parsing the monitoring values is at fault.
Don't know why I didn't already think of that from the start before building specific versions to test.. ?

Seraksab

Well damn :/
That's really a bit of a frustrating issue, as it would be soo much easier and quicker if I could just test this on my machine..

Could you guys maybe download and run the standalone versions of OpenHardwareMonitor and LibreHardwareMonitor besides MoBro for a bit to check if those also keep increasing in memory?

Just to check whether the leak is already in their code or maybe my code reading and parsing the monitoring values is at fault.
Don't know why I didn't already think of that from the start before building specific versions to test.. ?

No worries.  I have both running and will report back in an hour or so.  

Interestingly, Libre is the one that is climbing on my system.  After 40 minutes it hit 100mb whereas OHW is steady at ~18 throughout.  

Seraksab

Well damn :/
That's really a bit of a frustrating issue, as it would be soo much easier and quicker if I could just test this on my machine..

Could you guys maybe download and run the standalone versions of OpenHardwareMonitor and LibreHardwareMonitor besides MoBro for a bit to check if those also keep increasing in memory?

Just to check whether the leak is already in their code or maybe my code reading and parsing the monitoring values is at fault.
Don't know why I didn't already think of that from the start before building specific versions to test.. ?

Hey bud, it only happens while running the Pi. Not as a standalone monitor via pc. Tested this morning 

After an hour of just Open Hardware monitor it's up to almost 60MB. Climbs at the .1 - .3 MB/s previously reported.

4c7e3a9f-5ed5-4e02-9c23-88aa2dd158df.ee851716.png

Login to comment

Login
Like most websites, we also use cookies. But don't worry, we only use them for your login and statistics.