Possible memory leak with ReportViewer.RefreshReport() ReportViewer内存回收缺陷
I'm creating a VB.NET front-end application for viewing reports in local mode. I noticed that ReportViewer.RefreshReport() seems to be generating a memory leak by observing my application's memory with Windows Task Manager. It seems successive calls to this method cause the memory to increase. This memory is not released when I close the report. Is anyone else having this issue? If so, how did you solve it?
----------------
There are actually two problems here. Running a report requires the report processing engine to generate and load an assembly in order to evaluate expressions in the report. By default in local mode, this expression host assembly is loaded into the main appdomain. Since assemblies can't be individually unloaded, it remains loaded permanently.
Local mode does have the option to run expressions in a sandboxed appdomain (ReportViewer.LocalReport.ExecuteReportInSandboxAppDomain()). However, there is currently a bug that this appdomain does not get unloaded at the appropriate time. We are currently working on a fix for this and hope to get this into VS 2008 SP1. If you need a fix sooner, customer support may be able to provide additional options: http://support.microsoft.com/contactussupport
----------------
To anyone else who is interested, here are some other threads on this issue:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=449474&SiteID=1
http://www.scitech.se/blog/index.php/2007/10/05/memory-leak-in-toolstriptextboxcontrol/#comment-1295
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=305199
Also, note that monitoring memory usage with Windows Task Manager can be misleading (the Mem Usage column just shows the working set). It's better to use other utilities like perfmon.exe or WinDbg in conjunction with Task Manager.
----------------
The information on those other threads is correct, but that's the same issue I descibed. The event handler problem was causing the report viewer to keep the entire report snapshot around. This includes the compiled report definition as well as some of the report data. That's certainly much larger than the expression host assembly I mentioned. This issue (as it pertains to the ReportViewer) was fixed in VS 2008.
----------------
I downloaded the Visual studio 2008 trial version and checked out the ReportViewer Control. I see that the memory leak with ReportViewer is still very much there.I used a third party profiling tool (YourKit) to check the memory. The ReportToolBar is one reason why the ReportViewer reference is not GCed. There are also a bunch of other EventHandler classes (such as searchEventHandler, ExportEventHandler ,ZoomChangedEventHandler etc) which are holding references to the ReportViewer. This control is so cool but for the memory issue.
Was there any update that I have to install after I install VS 2008 ? Any info. on this would be very helpful..
To see the memory leak, all we need to do is to invoke a WinForm with a ReportViewer Control on it. We dont need to add datasources etc. Just opening and closing this Form from another Form will be enough to see the leaks.
----------------
As far as I know, these issues were fixed in VS 2008, so I'd like to take a closer look at your project. Will you file a bug at http://connect.microsoft.com and attach the project you are using? That's probably the easiest way to get it into our tracking database.
----------------
I observed the same problem using, in a batch process, iteratively the method ReportViewer.Render.
This causes a very problematic leak, my intention was to use ReportViewer to produce a lot of PDF documents (invoices) (> 5000 or more) and this leak forces me to stop-restart this batch process.
In other answers you say that the fix for this problem will come in a Microsoft ReportViewer for VS 2008 SP.
Is it possible to have a fix for this for .NET 2.0 (that is, with Microsoft ReportViewer for VS 2005)?
In my production systems for now I have .NET 2.0 Runtime installed and for now I have no time and plan to pass to .NET 3.5 to run the fix.
For now I haven't a plan to use Microsoft ReportViewer for VS 2008 (from Microsoft site, the Redistribuitable package requires to install the .NET 3.5 runtime) and .NET 3.5 runtime.
Then, is it possible to have a fix for this problem that runs on .NET 2.0 Runtime?
----------------
----------------
----------------
----------------