StrokesPlus Forum
StrokesPlus Forum
Home | Profile | Register | Active Topics
Members | Search | FAQ
 All Forums
 Bug and Issues
 New Bugs
 Aggressively Manage Memory problems

Note: You must be registered in order to post a reply.
To register, click here. Registration is FREE!

Format Mode:
Format: BoldItalicizedUnderlineStrikethrough Align LeftCenteredAlign Right Horizontal Rule Insert HyperlinkInsert EmailInsert Image Insert CodeInsert QuoteInsert List

* Forum Code is ON
Smile [:)] Big Smile [:D] Cool [8D] Blush [:I]
Tongue [:P] Evil [):] Wink [;)] Clown [:o)]
Black Eye [B)] Eight Ball [8] Frown [:(] Shy [8)]
Shocked [:0] Angry [:(!] Dead [xx(] Sleepy [|)]
Kisses [:X] Approve [^] Disapprove [V] Question [?]

Check here to subscribe to this topic.

T O P I C    R E V I E W
ov2k Posted - 08/30/2019 : 18:06:46
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
4   L A T E S T    R E P L I E S    (Newest First)
beholder Posted - 08/31/2019 : 06:02:22
Guys, this is top-notch work you're doing here. Awesome.
Rob Posted - 08/30/2019 : 21:06:58
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.
ov2k Posted - 08/30/2019 : 20:38:16
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().
Rob Posted - 08/30/2019 : 18:47:51
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. 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 to avoid potential issues like this which would be very difficult to find.

StrokesPlus Forum © 2011-2018 Rob Yapchanyk Go To Top Of Page
Snitz Forums 2000