StrokesPlus Forum
                       
StrokesPlus Forum
Home | Profile | Register | Active Topics
Members | Search | FAQ
Username:
Password:
Save Password
Forgot your Password?

 All Forums
 Bug and Issues
 New Bugs
 Aggressively Manage Memory problems
 New Topic  Reply to Topic
 Printer Friendly
Author  Topic Next Topic  

ov2k

2 Posts

Posted - 08/30/2019 :  18:06:46  Show Profile  Reply with Quote
StrokesPlus with the preference Aggressively Manage Memory (AMM) enabled interferes with VirtualBox, at least some of the time. On a Windows 10 system with 6GB of RAM available to the OS and 3.8GB available to VirtualBox, a VM using 3GB of RAM runs out of memory when AMM is enabled in StrokesPlus. Delayed allocation by VirtualBox means some effort is usually necessary to trigger an error (e.g., checksumming more than 3GB of data). The VM runs fine when the option is disabled. The issue likely manifests with other programs that require large amounts of RAM and on low-memory systems.

I know StrokesPlus is out of support, and I'm not expecting any changes. This is more to document the issue and workaround and hopefully provide enough information to avoid the issue in StrokesPlus.net.

Rob

USA
2591 Posts

Posted - 08/30/2019 :  18:47:51  Show Profile  Visit Rob's Homepage  Reply with Quote
That's interesting.

There's not really anything fancy going on there, it's just making a single WinAPI call to SetProcessWorkingSetSize().

The truth is when I was starting out S+ I wanted to have a low running memory footprint. Not knowing a lot about how to do this in native WinAPI/C++, this was just a hack to force releasing all pages.

This is the first report I've ever heard of it, but of course it would not be a very easy thing to narrow down to S+ being the culprit.

S+.net wasn't doing things quite the same way, because it's .NET...never going to have a tiny footprint anyway! But I was trimming the memory after closing memory heavy things like the Settings window. However, I'm going to remove that as well and just call GC and let it do its thing. Might not look as nice in Task Manager, but these days who really cares?!

Reading up on that API call this evening, basically the guidance is "Don't use it unless you really know a lot about memory management."

I don't claim to be an expert or even intermediate level, so I think I'll just take it out (of S+.net) to avoid potential issues like this which would be very difficult to find.
Go to Top of Page

ov2k

2 Posts

Posted - 08/30/2019 :  20:38:16  Show Profile  Reply with Quote
If you're curious, GoogleCrashHandler64.exe used to have a similar conflict. They tracked the bug down to an "unintended typecast" in their call to SetProcessWorkingSetSize().

https://github.com/google/omaha/issues/38#issuecomment-116893246
Go to Top of Page

Rob

USA
2591 Posts

Posted - 08/30/2019 :  21:06:58  Show Profile  Visit Rob's Homepage  Reply with Quote
Yep, I saw that. I don't have any casting going on, just explicit parameter values being passed in.

Either way, there's no reason for me to try to manage memory for a utility app like this, just let the OS handle it accordingly. Now I have found and fixed some memory leaks in both the original and .net version, but this would only serve to conceal those longer anyway.
Go to Top of Page

beholder

60 Posts

Posted - 08/31/2019 :  06:02:22  Show Profile  Reply with Quote
Guys, this is top-notch work you're doing here. Awesome.
Go to Top of Page
   Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
StrokesPlus Forum © 2011-2018 Rob Yapchanyk Go To Top Of Page
Snitz Forums 2000