Ticket Q496851
Visible to All Users

Possible memory leak XafReports

created 12 years ago

Hello,
In our application we use on different places XafReports.
For example for creating invoices each month. This invoices are sometimes printed. Not 4 but 150+.
Because of the heavy operation one of our customers had a OutOfMemoryException.
After searching for the problem we analyse the memory with .NET memory analyzer.
We found a memory leak in XafReports. We have tried in the maindemo too and can reproduce the problem.
The steps to reproduce:
- Open an report
- Close the report
- Open the other report (you get the popup for task status)
- Close the popup
- Open again the first report
- Close the report.
I had the following results (graph of results in attachment):
* The application before opening: 20.472.716 bytes (~20.4 MB) (Point 1 in image)
* When report is opened: 22.933.581 bytes (~22.9 MB) (Point 2 in image)
* When closing the report: 23.655.589 bytes (~23.6 MB) (Point 3 in image)
* GC cleans up: 22.188.319 bytes (~22.2 MB) (Point 4 in image)
* Other report opened: 24.256.107 bytes (~24.3 MB) (Point 5 in image)
* Close the report: 23.514.175 bytes (~23.5 MB) (Point 6 in image)
* Open the first report again: 24.102.956 bytes (~24.1 MB) (Point 7 in image)
* Close report: 24.608.736 bytes (~24.6 MB) (Point 8 in image)
With this numbers we can make the conclusion that for some reason not everything is cleaned up correctly and the memory goes up.
Ok, this is a small application with 2 reports which are opened and closed again twice. However in our application we have at least 500 reports so the impact will be bigger and bigger.

Show previous comments (6)
Dmitry M (DevExpress) 12 years ago

    Hello Wim,
    You seem to have already created a small example that stably reproduces this behavior. So, would you please send it to us for internal examination? This will allow us to investigate this behavior and provide you with a solution as soon as possible.
    I created a small example that prints out a report 500 times (printing to a file), and this scenario works fine for me. It uses only XtraReport. Please find a sample attached to this message.

      Hi Dmitry,
      Sorry for my delay. I have been on holliday and very busy so want be able to respond earlier.
      I watched/investigate your application. Your application makes it already possible to show the problem.
      I attached a image with the memory usage. The white line is Live bytes, this are the bytes when garbage #2 collects. The pink line are the bytes in memory which are not collected yet.
      From 0 min to 2 min I opened one report, closed and waited. I expect the garbage collector should cleanup so the pink line will fall down to the white line. After that I opend multiple times the preview of the report. You see that the GC is doing a good job and cleanup in peaces and goes back to the beginning.
      From 4 minutes I start printing the reports, there you can see the memory is increasing very slow. I should expect that the white line while printing, fall down to the same level as in the beginning.
      It could be possible that XAF keep objects reserved so the GC cant cleanup. But back to my previous point.
      If I start for example with 5 MB of memory, I open a window, the object(s) will be created, but when I close, this objects are not needed anymore so the memory should decrease back to his previous point, 5 MB.
      In the same image I have on the bottom a image of our application. XAF use a LOT memory, we precompile some things in a other thread for faster working. When the graph stops increasing, I printed 20 reports. As you can see the white circles (= point where GC #2 cleaned up) is everything back to the main.
      I hope I can make it more clear for you right now, otherwise, just ask :-)
      Kind regards,
      Wim

      Dmitry M (DevExpress) 12 years ago

        Hello Wim,
        In fact, it is not guaranteed that the CG will be called automatically after a period of time.
        During the normal application life cycle, GC may not be called at all, unless its garbage collection is forced by the CLR.
        You can learn more on how the GC works at http://msdn.microsoft.com/en-us/library/ee787088.aspx#conditions_for_a_garbage_collection.
        Now please let me elaborate on how we find memory leaks in .NET apps internally.
        For example, you may want to check for memory leaks when a report preview is shown.
        Here are the steps you would perform:

        1. Run the application under the profiler and open the report preview;
        2. Close the report preview;
        3. Now we will make a single snapshot. Take note that we did not make a snapshot before the report preview was closed, because at this stage not all static variables and other resources can be loaded and properly initialized;
        4. Open the report preview once again;
        5. Close the report preview;
        6. Make the second snapshot.
          You can learn more about these steps in the documentation of your preferred memory profiler. For instance, we can also use the .NET Memory Profiler:
          http://memprofiler.com/OnlineDocs/default.htm?turl=findmemoryleaks.htm.
          At this stage we can analyze the difference between these two snapshots to see whether there are any memory leaks.
          In particular, we are looking at the following columns:
        7. Column Live bytes / Delta
        8. Column Live instances / Delta
          Refer to the http://memprofiler.com/OnlineDocs/default.htm?turl=overviewpage.htm help article for more details.
          As for the Real-Time Page, it only provides auxiliary or supporting information, and does not allow you to determine a memory leak:
          http://memprofiler.com/OnlineDocs/default.htm?turl=realtimepage.htm.
          I hope this information helps.

        Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

        Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.