MemoryLeak in StiReport.Render

[MasaMM]

Hi,

I've got a background application which periodically exports reports. This application may run for weeks or month without shutting down, so it's very important that there aren't any memory leaks.
I was able to locate the memory leak being caused by the StiReport.Render/RenderWithWPF/... methods. It's only a couple KB per export but this accumulates over hours/days which finally caused a OutOfMemory crash.

Can you please check those methods for memory leaks?

[Alex K.]

Hello,

Please clarify which version are you use?
Also, please check the last version. We have made some improvements and optimizations in that direction in last versions.

Thank you.

[MasaMM]

I was using 2016.1 but just upgraded to 2016.2 and the memory leak still exists.

[Alex K.]

Hello,

Some principles of the functioning:
1. Source code of the report is formed. Forming based on the grounds of meta description of the report
2. This source code is compiled in to assembly
3. Assembly is loaded in to memory
4. Create object of the report from loaded assemblies
5. Report is rendered
6. Report is showed

The loaded assembly occupies place in memories. If ten once produce compiling the report,
that will be ten are once created assembly of the report and loaded in memory. How to correct?
Regrettably .Net Framework does not give the possibility to unload the assembly from memory
(only together with application domain, but this method has much restrictions).

1. Save the report as class and add it to project. In this case compiling occurs
together with project.
2. Save the report as assembly. Before building of the report its necessary to load
from assembly with method StiReport.GetReportFromAssembly.

Method has two variants of the work:
1.

Code: Select all

StiReport report = StiReport.GetReportFromAssembly("myreport.dll");

Report will is loaded in memory exactly so much once how much will is caused this method,
but at file of the assembly of the report will not be locked.

2.

Code: Select all

StiReport report = StiReport.GetReportFromAssembly("myreport.dll", true);

Report will is loaded in memory only once even though cause the method over and over again.
At file of the assembly will be locked before closing of application (blocking leaves only after
closing of application). Use of this method does not cause the memory leaks since assembly
of the report is loaded in memory only once.

Loading the reports from assemblies has one unpleasant minus - it is necessary beforehand to
prepare the assemblies of the reports. But minus possible easy avoid. Idea is concluded in that
to produce compiling the report under the first start the report on building:
1. Check, there is file of the compiled report on disk?
2. If file there is, that loads report from assembly and start on execution
3. File does not exist, then compile the report in to file (compiling will is made in any cases)
and start the report on execution.

Under following start the report on execution he will is loaded from file. Example of the code:

Code: Select all

StiReport report = null;
string compiledReportFile = "report.dll";
if (File.Exists(compiledReportFile))
{
        report = StiReport.GetReportFromAssembly(compiledReportFile, true);
	report.RegData(“MyData”, dataSet);
	report.Render();
}
else
{
	report = new StiReport();
	report.Load(file);
	report.RegData(“MyData”, dataSet);
        report.Compile(compiledReportFile);						
	report.Render();
}

Note: If report is loaded from assembly, that speed of the building of the reports
much above since compiling is not required.

About data. If object of the report iexist in memory long time, that necessary to clean
the references to data after building of the report is finished:

Code: Select all

Report.Dictionary.DataStore.Clear();

If report was compiled, that in addition:

Code: Select all

Report.CompiledReport.DataStore.Clear();

Thanks.

[Alex K.]

Hello,

Also, you can use the Interpretation mode for the report.
If the memory leaks in the exporting, please send us a simple project which reproduces the issue for analysis.

Thank you.