Serious memory problem in 3.08.1 on all VST - even stock!

[Youlean]

There might be some bug related to Ruby when drawing graphics as far as I see.

[Spogg]

...After about 6 minutes of wiggling the knob....it seems much slower then other tests but still leaks.
Therefore I will suggest you guys on Win 7 test this again , taking into account that its slower then other leaks....

I did re-test as you requested but I didn't get the leak with tulamide's knob (I love writing that )

Also this time I tried it on Windows 7 x64. The memory started at 17,144 then went up quickly (with rapid tweaking) to 17,660.
After that I could only get changes between 17,660 and 17,784 and nothing I could do would make it go any higher.
When I deleted the knob the bridge closed and the memory was fully released.
It's possible, maybe, that all the knob views are cached until they've all been seen once, then drawn from memory rather than be re-created every time. But hey, what do I know?

I think we need to be patient now and wait until the bug in the Ruby export between 3.06 and 3.08 is found.

It would be interesting to check out the issue in other DAWs though. Plus I cannot account for what I saw in Windows 10. My plugins were fine but the solitary knob leaked.

Cheers

Spogg

[lalalandsynth]

Yes, I am setting up a test in Live and Cubase tomorrow.

"I think we need to be patient now and wait until the bug in the Ruby export between 3.06 and 3.08 is found."
Yes, although I am not entirely convinced mostly because this volume knob leaks on 2 win 7 machines I tried but will not budge on win 8. Also , you see no problems on win 10 , whereas you see the problem on Win 7, there is something fishy going on here.

I also suspect other equally bad problems with ruby , doing some testing. Want to be absolutely sure.

[tulamide]

I also suspect other equally bad problems with ruby , doing some testing. Want to be absolutely sure.

I'm no friend of accusations. We tend to point a finger to what we don't know. And that's wrong. Ruby is a script language. It's nature forbids any leaks. The GC takes care of all the memory and it is rock solid. There are only two ways to make Ruby itself a "leaker":
1) Misusing Constants. A constant, as the name implies will never be freed from memory until Ruby quits. There are no misused constants in my Ruby code. In fact there are no constants at all.
2) Forcing a leak by writing and precompiling C-code enhancements, for example via a Gem. One could write a memory allocation in C without writing a memory release function. Then pre-compile it for a Ruby extension and implement it via 'require'. I haven't done so. There's no extension at all. It's pure core Ruby.

The same goes for other issues. If Ruby misbehaves, the programmer created a bug. That's not Ruby's fault. It's a slip-through caused by the programmer (see my mouse cursor disappearing issue).

The current issue is a Flowstone issue, not a Ruby issue. Flowstone handles something wrong in the process of embedding Ruby scripts in the dll. It will be detected, corrected and everything will run as smooth as in 3.0.6 again (man, am I glad I always sticked to that one version )

[lalalandsynth]

I meant in the implementation of Ruby in FS. A suspicion, not an accusation...

Also , so far , the fact that the volume knob leaks on two of my win7 machines, has not been addressed.
I personally don't have the skills to even make a guess as to why that is ?

[Spogg]

It seems that from Windows 8 onwards the memory management has been improved considerably.

This article (about half way down the page) explains what we may be seeing (some of it anyway) in the difference between Win 7 and later versions:

http://www.askvg.com/comparison-between ... nt-system/

Unfortunately when I tested Flowstone under Windows 10 it all worked but would not save a schematic. All looked well but the saved schematic wasn't there. I believe others are using Windows 10 with FS but that was the problem I had. When I tested the then current alpha version it did save ok, so hopefully this won't be an issue when 3.09 is released.

Of course I think it's not good practice to lean heavily on the OS to mask an exported VST with dodgy Ruby embedded.

Cheers

Spogg

[tulamide]

Of course I think it's not good practice to lean heavily on the OS to mask an exported VST with dodgy Ruby embedded.

I'm not sure if I misread this, because to me it sounds like once again saying that Ruby is a bad boy. It is far from being dodgy. The fact that it is rock solid is so welcome, that it is used a lot on the internet as Ruby on Rails. You probably visit half a dozen sites daily that rely on Ruby to deliver.

Once again, the issue is a mistake by the programmers of Flowstone, wether you want to hear it or not. So, the sentence would make much more sense using it this way:

Of course I think it's not good practice to lean heavily on the OS to mask an exported VST made with dodgy Flowstone.

[Spogg]

Yeah I could have phrased that better

I 100% accept that the actual Ruby is fine, otherwise this would have been a problem for ever. It's how it's being exported in flowstone 3.08+ that's the issue for certain.

Sorry for any misunderstanding.

Cheers

Spogg

[MyCo]

I'm still not convinced that this is a bug. I can see it on my Win10 machine it's increasing very slowly when tweaking a knob (about ~0.02MB per second). I don't know how high it'll go, and certainly not keen to test this as the machine has 233GB of free RAM to waste.
As I read, the memory increase reduces over time, which indicates to me that everything is just fine.

My assumption is like that: Ruby is VM which manages it's memory dynamically. This means it allows itself to allocate as much memory as it wants to a certain limit (depending on the free mem reported by the OS, but max. 3GB as that's the 32Bit limit). When the OS reports "hey I have ~100GB of free mem", then Ruby just doesn't bother and allocates more memory when need, without ever freeing it. On a low memory system, Ruby might free the memory after the garbage collector ran (which is slow!). On a high memory system ruby runs the garbage collector but keeps the memory allocated so it can use it whenever it's needed.

To be clear, the memory is allocated... but internally not all of it is used.

However there is one odd thing to it: It happens only in the VST and not in FS, and I've no clue why... There is no different setup for the Ruby Interpreter in the VST. It might have something to do with the clock rate that is used to "contact" the ruby interpreter. So the interpreter is a bit more "busy" and therefor doesn't clean up as thoroughly?

[MyCo]

BTW: here is a test schematic that I came up with to get infos from the Ruby GC... but I didn't really see much with it