Forum

Memoryleak in Text (EX9) Plugin

vvvv beta question
#1

helo,

it seems that the text plugin (v25.1 as well as v26) has a serious memory leak. Every time the Text-Input changes, a new block of memory is allocated but never will released again. (utf8 as well as ansi)

a guess is that it has something to do with the drawString method and a missing Dispose somewhere.

cheers,

i.

ex9Text_MemoryLeak.v4p (3.1 kB)

#2

this seems a serious bug to me. since most e.g multilanguage exhibits probably using text (ex9).

devvvs. any chances this could be fixed soon? tonfilm, joreg?

#3

confirm this bug!
if you create new Text(EX9) node in beta26 you’ll face this memory leak.
Text nodes in a patch created in beta25.1, are opens in beta26 as Text (EX9.Legacy) and have no memory leak at all! so it solution for licensied users for now.

#4

hmm. bo’s “solution” does not work for me. still got an increasing memory usage. deleting or reseting the node de-allocates the memory though.
gregns. any idea?

#5

while disabling (enabled pin) the node in beta25.1 doesn’t change anything, in beta26 it de-allocates the memory.

though in beta26 from the beginning the requirement for memory is 3 times as high as in beta25.

#6

first of all this is NOT a memory leak. by deleting the node, removing the layer connection or disabling it the memory consumption goes back to normal (though we call the last one an undesired behaviour, because it leads to glitches). so all resources are cleaned up properly.

the plugin uses ID3DXFont::DrawText to draw the text. this method caches each character it has to draw in form of a texture. the size of the texture depends on the size of the text.

this test patch creates about 100 new characters each second.

in case of ANSI there are only 256 characters, the internal texture cache of DrawText will therefor be filled after about 3 seconds. in case of UTF8 there are up to 2^32 characters, so it will take about 1.3 years (!) till the cache won’t miss anymore ;)

you can easily test this by adding a modulo of 256 to the test patch. switch between ANSI or UTF8 and the memory consumption will stay the same.

sadly we can’t do anything about the caching behaviour of the DrawText method, but what we can do is adding a few hidden pins in order to release all resources and therefor lower memory consumption and pins to control the pre-loading behaviour of various characters. hope this helps.

© vvvv group