Memory Leak in SyntaxEditor

I'm not sure what would be keeping it open. In 2.5 we went through the entire object model to ensure that all timers, GDI objects, etc. were disposed, especially when you call Dispose on the SyntaxEditor class.

If you are able to determine what is keeping it from being disposed, please let us know.

With all due respect, it is not Nicols job to determine what the problem is. He has determined, and can reproduce, that a problem exists with SyntaxEditor holding on to a reference somewhere. Since neither he, nor any of your other customers have the source for SyntaxEditor itself, it seems to me the onus of determining the source of the memory problem falls to Actipro, not Nicols.

When opening a 5MB log file, for example, my memory utilization spikes up to 190MB. Then after closing that instance of SyntaxEditor, the memory is never released, this is all viewable from Task Manager. Even if both SyntaxEditor.Dispose() and GC.Collect() is called in either my code, or even if those lines are added to the sample app, the memory is never reclaimed. This is all a clear indication that somewhere inside the syntaxeditor.dll, or one of its supporting shared libraries, one or more references aren't being released properly.

This is a serious enough issue that I would sincerely hope Actipro puts enough resources behind this problem to solve it. This is a terrific product and I'm a big supporter but this really needs to be addressed.

I am agree with Marianne. For me is a very serious issue, I think that SyntaxEditor is a great product, but I am consider not upgrade to version 2.5 for this issue.

In version 2.0, there is a memory leak too. But, I could solve it invoking the method ResetLanguage and set AllowDrop to false when I don't need the Syntaxeditor anymore. In version 2.5 I couldn't detect a way to avoid this. With an ofuscated code and without the source code, it is almost impossible to perform a memory profile to detect the problem.

What software products or methods do you recommend for helping determine what is not being released?

The best thing that I've found is the Microsoft CLR Profiler:
<A HREF="http://msdn.microsoft.com/msdnmag/issues/03/01/NETProfilerAPI/default.aspx" TARGET=_blank>http://msdn.microsoft.com/msdnmag/issues/03/01/NETProfilerAPI/default.aspx</A>

That's some information on the profiler and how it's used. The actual download of the latest version is here:
<A HREF="http://www.microsoft.com/downloads/details.aspx?FamilyID=86ce6052-d7f4-4aeb-9b7a-94635beebdda&DisplayLang=en" TARGET=_blank>http://www.microsoft.com/downloads/details.aspx?FamilyID=86ce6052- d7f4-4aeb-9b7a-94635beebdda&DisplayLang=en</A>

There are also some 3rd party profiling tools but I've never used them so I don't know how they compare to the CLR Profiler.

There are some tools that help you to see what is in the memory (you can download a trial version):
.Net Memory Profiler (http://www.scitech.se/memprofiler/)
GlowCode .Net (http://www.glowcode.com/summary2_net.htm)

But, with a big application is easy to lost yourself inside a lot of object instances. So, for me the best method to discover the failure points with this scenario is comment/uncomment code until I identify the problem. In this case, you only have to work with SyntaxEditor constructor (and called objects) and check the IsAlive property in a WeakReference.

Good luck!!!

I was noticing this problem as well.
While monitoring it through .NET Memory Profiler, i noticed this:
<IMG SRC="http://users.skynet.be/bk291750/memory.jpg">
This graph represents live instances.
Green: Commandlink
Yellow: Editor (own extension of SyntaxEditor)
Pink: EditorView
Gray: GC(level 0,1,2 (you can't really see the twos, but there are some))

I get the impression the commandlink-graph "grows" much faster then the others, or am i not correctly interpreting this graph?

Edit: on second thought, i might just be completely wrong <IMG SRC="wink.gif" border="0">

[ 12-30-2004: Message edited by: byperman ]

Good news... by using some of the memory profiling utilities, we were able to find the 3 references that were preventing SyntaxEditor from being finalized as Nicolas originally posted. In a test app with your original post's sample code, it now returns that SyntaxEditor is no longer alive. This update will be in the next release.

Great News! Out of curiosity, which tool proved to be the most beneficial in tracking this down?

I tried several of them.

The CLR Profiler gives a lot of information however it was difficult to find what information I'm looking for, namely retained references.

The GlowCode one wasn't very good in my opinion and didn't give much useful information at all.

The .Net Memory Profiler (http://www.scitech.se/memprofiler/) ended up giving the most useful information. It clearly indicated which instances of objects were not being released and it made it easy to find what other objects referenced them. For anyone doing memory profiling, I would recommend this product.

Sweet! Glad ya caught that one. <IMG SRC="smile.gif" border="0">

BTW, how often do these new releases come out? Is this near-term or one of those months away things?

-- David

Hoping to release it tomorrow. If you'd like to check it out and help test it, send us an email and I'll send you a link to it.

I was going to post some memory profiling I did on SyntaxEditor but nevermind.

For another good profiler, check out ANTS from Red-Gate (www.red-gate.com I believe). This is a memory and performance profiler but I have been using it for past couple weeks and it really helped my apps (especially the performance piece). I used the mem snapshots on Actipro dlls and was gonna post what it found but looks like you got it resolved.

Thanks

[ 01-08-2005: Message edited by: painetraine ]

If you'd like to email your findings to us, it can't hurt. They might be useful in case we missed something. Thanks!

[ 01-09-2005: Message edited by: Actipro Software Support ]

Just checked out build 156 and looks great! Behaves exactly as expected.

Hi,
We are using v2.0.0108 of the ActiPro SyntaxEditor .NET Control. Out product is integrated and released to Market with this version 2 years back. We have a customer who recently reported an issue of Memory leak. On close observation we have seen that User Objects count in the Task Manager is increasing. I am putting it in the same thread as it is related to the same issue. Was there any hotfixes or patches available for this issue. We cannot upgrade to the new version as it is already in the market.

The leak happens when we execute the following command
ActiproSoftware.SyntaxEditor.SyntaxEditor x;
x = new ActiproSoftware.SyntaxEditor.SyntaxEditor();

But when we do a Dispose method as above we are not seeing the Object Count decreasing.
Any workaround or fixes for this will be greatly appreciated.

Thanks,
Prashanth Kota

Hello, actually that version you have came out 4 years ago.

At this point, there have been so many changes made to SyntaxEditor since then, it's hard to say what fixes were put in place to address the memory issue. However from this thread it appears that it was resolved in v2.5. Perhaps you would consider moving to the latest v2.5 maintenance release, which would have a few breaking changes that may not be hard to do (all documented in the release history) but not nearly as many as stepping up to v4.0. Email us with what you'd like to do and we can discuss options.

Thanks for the quick response. This issue is a very high priority for us as our customer has been waiting on the fix from quite sometime.
We already have dev license for v4.0, but unfortunately we cannot just move to this version as it involves regressing the entire product again. We are in a phase where we have to release a quick fix for this, so any suggested fix for this will help us a great deal.
Also we wanted to know from where we can download the v2.5 or the hotfixes for v2.0.

Thanks,
Prashanth Kota

I understand, just email us at our support address with your organization name (licensee) and we can set you up with the latest v2.5. The latest v2.0 maintenance release is probably already available for download in your account, however I don't think it did anything to address memory issues.

Hi,
One more question. Even if I plan to go with v4.0 then, are they backward compatible with v2.0. What is the impact of switching to v4.0. Is it just a recompile with new dlls or does it require any code change from our side.

Thanks,
Prashanth Kota

Hello, yes as I mentioned earlier there are breaking changes although stepping to v2.5 has less breaking changes. All our changes are marked clearly in the Release History in the readme file. So you can see the entire history in there if you have v4.0 installed. If you need more help on this then please email us instead of posting here.