Big Memory leak with Ribbon Window!!!!

Ribbon for WPF Forum

Posted 12 years ago by Arthur Damen
Version: 11.2.0554
Platform: .NET 4.0
Environment: Windows 7 (64-bit)
Avatar

I have found a big memory leak inside the ribbonwindow,

in my case the user has a main wpf application and opens a second window that is a ribbonwindow.
This window is opened/closed repeatedly. Each time the window is opened about 15-20MB is used, and NOT freed after close of the window.

Please solve this ASAP because this eventually crashes our application.

TO REPRODUCE:

-To get this reproduced i openend the actipro example browser (exe).

-next choose ribbonbar

-select demos/document editor (like word)

-now open the task manager and select the actipro program and write down the memory usage

-in the actipro sample browser hit the "Run external sample"

  you will notice an increasement in memory (this is of course normal)

-next close the external sample window.

  you will notice that the memory is not released!

-repeatedly open/close this sample window will increase the memory

Comments (4)

Answer - Posted 12 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Arthur,

One problem here seems to be with a WPF core memory leak with BitmapImage.  If you use our RibbonCommandUIProvider class and the constructor overload that takes string parameters (like our sample currently does), that constructor will create a new BitmapImage.  However something core to WPF is retaining that and since it ends up being used in UI, the UI gets retained as well.

One workaround we found was to use full path:// syntax to create a BitmapImage and then call Freeze() on the BitmapImage that was created.  If you do that in your own app and pass us the resulting BitmapImage instead, that will help with this particular issue.  We also have updated our code for the next build to freeze the BitmapImage we create if pack:// syntax is used.  If it isn't, then the BitmapImage will appear blank if we try to freeze it, so we don't freeze in that case.

The second issue we found was how when PopupGallery.CategorizedItemsSource is set we build a new ItemsSource.  Something internal to WPF is holding onto a reference to the control in that case.  We updated our code for the next build to work around this and prevent it from happening.  This will only happen if you are using categorized items in PopupGallery.

After tweaking those two things, there is no more problem.


Actipro Software Support

Posted 12 years ago by Arthur Damen
Avatar

Hi,

The popupgallery with categorised items is used by us which could cause this.

Our customers complaint about a long time before starting some (sub ribbonwindow),
I added a forum item 2 weeks ago about this, but maybe this has also to do with opening/closing the window
some times behind each other causing the memory to build up.

Do you know when a new (bug fix) version will be released?

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

Hi Arthur,

It will be as part of the 2012.1 release, which should be out in the next 2-3 weeks.  We could possibly give you a preview build of a 2011.2 maintenance release with the same fixes too, earlier than that if you'd like to test with it.  If that is what you'd like to do, please e-mail our support team.


Actipro Software Support

Posted 12 years ago by Arthur Damen
Avatar

I can wait 2-3 weeks. If the customer needs a solution earlier i wil contact support.

 

thanks.

The latest build of this product (v24.1.1) 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.