Question on Memory Leaks

SyntaxEditor for Windows Forms Forum

Posted 5 years ago by Mike Dempsey - Sr. Developer, Teradata Corp
Version: 14.1.0323

I'm having an issue with memory leaks when I create (and later dispose) a temporary SyntaxEditor object.

This object is created programatically at runtime - with no UI, no triggers, no outlining, etc.
It is then used to perform some parsing and is then disposed.
(while allowing the user to continue to edit the 'real' editor)

The new profiling tools in VS2015 showed that the leak was caused by a Document object and thousands of DynamicToken objects.

I found that by adding


the leak was reduced by about 30%, with virtually all the remaining leak related to DynamicToken objects and their related LexicalPatterns .

Since there is one and only one Document per editor it seems that this should be taken care of by disposing the editor itself - but apparently it is not.

My real question is how do I get rid of all those DynamicToken objects.

The profiler shows the reference tree to these objects as:



Comments (4)

Posted 5 years ago by Actipro Software Support - Cleveland, OH, USA

Hi Mike,

Documents are maintained separately from a SyntaxEditor control since you are able to swap documents in and out of editors if you like, or you can create documents without any editor instances too.  It sounds like for your situation, you might even want to just make a new document and not bother with the temporary SyntaxEditor instance.

But back on your question, as long as the Document goes out of reference scope from everything, there shouldn't be any leak.  Calling SyntaxEditor.Dispose(true) will remove the editor's tie to the document and should allow it to be collected, unless you have something else that is referencing it.

Actipro Software Support

Posted 5 years ago by Mike Dempsey - Sr. Developer, Teradata Corp

I was not aware that I could create/use a Document that was not hosted within a SyntaxEditor. It does sound like something I should try.

I thought the Document should be disposed when I disposed the editor but it definately said it was still using memory if I didn't specifically dispose it first.

Any ideas on how to get rid of all the DynamicTokens that seem to remain?

There are no other references to the temporary editor (or document) but the Language I assigned to the temporary editor's Document was the one in use in the 'real' editor. Since the real editor still exists could that cause it to hang onto the tokens it created for the temporary one?
(If so I could load the language from file again so that there was no reference ... but I avoided that since I thought 'reuse' would be faster and require less resources that a second copy of the Language.)

Posted 5 years ago by Actipro Software Support - Cleveland, OH, USA

Hi Mike,

When you set the Document.Language property, it does attach to the SyntaxLanguage.Changed event, which could possibly hold a ref if you also ref the language elsewhere. However as long as you call Dispose(true) on the temp SyntaxEditor instance and then also on the Document that was attached to it, that should clear the event tie.

If you still have problems after trying that, please make a new simple sample project that shows the issue and email that to our support address in a renamed .zip file extension so it doesn’t get spam blocked. We’ll use our memory profiler to debug what’s happening.

Actipro Software Support

Posted 5 years ago by Mike Dempsey - Sr. Developer, Teradata Corp

Thanks. I found the remaining issue.

I had forgotten that I also had a second editor used to display a log while the query was running.
When I added a line to dispose the Document within that editor the leak went away.

Even though I never held any references to the Document objects within these editors those documents did have a language attached to them and that language was re-used so it would never be released. If the language maintans a pointer to the Document that would explain why the Documents remained even after I disposed of the editors. 

The latest build of this product (v2020.1 build 0401) was released 2 months ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.