11/06/2012 18:30 ian Cook wrote:

Hi Oleg I am fairly sure there is memory leakage in FRB. Using your abc example and running the Vendors.rpt report I ran the same report over and over again. Task manager showed an increase of about 200k each time the report was run. It is even worse if a frame if Multiline Text is true. It then used about 500k each time the report was run. This has created serious complications for me when generating pdf's for each invoice. After about 250 invoices the memory usage climbs to over 500000k and the program hangs. If I run a non FRB report there is no memory leakage. Can you please investigate it to see if you have the same result in memory loss with FRB. Thanks. Kind regards Ian Cook PS Using version C8 Build 9661 and FRB version 3.31

11/07/2012 06:50 Oleg Fomin wrote:

Ian, I have seen your post at the NG. My reply is as follows. Do you have "FRB Report to RTF - Global" extension template in the app? If you don't need RTF output in this particular scenario, then I strongly recommend you to turn it OFF. Point is that Fomin RTF output generator consumes considerable amount of dynamically allocated memory. As far as I know, Clarion memory manager is trying to optimize memory allocation and doesn't return all the allocated memory blocks to system. To disable RTF output in RunTimeReport procedure you have few choices. 1) You can remove "FRB Report to RTF - Global" extension template from the app at all. 2) You can turn it ON/OFF conditionally at the procedure level using "FRB Report to RTF" procedure extension prompts: "Populate on report: Always|Conditional|Never" 3) If you prefer hand code, then you can find following generated code and set SELF.EnableRtfOutput = FALSE afterwards. ! Start of "After Opening Report" ! [Priority 3500] SELF.EnableRtfOutput = TRUE ! [Priority 8500] ! End of "After Opening Report" ! [Priority 8500] HTH, --- Oleg Fomin <oleg@fomin.info>

11/07/2012 09:52 ian Cook wrote:

Hi Oleg Thanks for the suggestion, but I do not have Report to RTF. I had already removed it. I only have Report To PDF. If you have any other suggestions I would be very happy to hear them. Kind regards Ian Cook

11/16/2012 05:42 Oleg Fomin wrote:

Ian, There is a relevant discussion at sv.clarion.clarion8 newgroup. Let me quote some words from there. "Robert Paresi" wrote in message news:A921.1352941200.2@discuss.softvelocity.com... > I've looked and looked and looked - I'm combed through the entire code > and sorted all the lines and verified everything is perfect. > > But, I’m told by someone there is a memory leak. I still don't see it. "robert.zaunere" wrote in message news:1_182_43315@discuss.softvelocity.com > JP, > > > > Remember one IMPORTANT thing though - our c8 apps do NOT hand back to > > os the ram used even when all is clean and well coded! > > That's 100% incorrect - you can do some reading (system committed memory, > process committed memory, working set memory, virtual memory, etc.) in order > to understand how the OS works with memory but suffice it to say that memory > marked for release back to the OS is not something you can monitor with > taskmanager or winevent. I did investigate possible memory leak, but cannot find it as of yet. Moreover, I cannot duplicate your problem on my computer. Please download my test application from http://www.fomintools.com/MemLeak.zip This application can generate either Clarion or Fomin report to PDF endlessly without any noticeable problem. Could you please modify this application somehow to duplicate and demonstrate your problem? Thank you, --- Oleg Fomin <oleg@fomin.info>

11/17/2012 18:36 Ian Cook wrote:

Hi Oleg Thank you very much for taking the time to generate the test program. I was able to replicate the problem on my computer. The only changes I made were - New button on main screen to edit the report - Edit the Fomin report to only print zip codes for state 'ME' - Edit clarion report to only print product code '1' I ran the Fomin report 200 times. The memory usage after 200 times was 216,068 K. The memory usage increased each time the report was run and would have eventually crashed. This is the same behavior I was getting on the customer site. I then ran the clarion report 200 times. The memory was always below 6,000K. After 200 times it was 5,124 K. Please check your email for the updated source code and reports etc. I am using Clarion v8 Build 9661. FRB v3.31 The computer is running Window 7 64 bit Let me know if you require any additional information. Kind regards Ian Cook

01/15/2013 11:19 Ian Cook wrote:

Hi Oleg On the 19 November 2012 you email me saying you were able to replicate the problem on your computer. Have you found anything yet? Here is a transcript of your email.. ---------------------------------------- "Ian, I haven't received an E-mail with updated source code from you. But I have modified my example with your instructions and I've got the app stopped working after ~300 times. Now let me some time to investigate and experiment. Thank you, --- Oleg Fomin <oleg@fomin.info> -------------------------------------

01/15/2013 18:05 Tom H. wrote:

Oleg, I can confirm that this is a serious issue with FRB 3.31. Running an FRB report with 68K records sucks all the memory out of the system and crashes at around 38K in our tests. We reverted to 3.12, which also seems to have a leak but not nearly as severe as 3.31. For this program we are using C6.3, multi-dll. Have you made any progress on resolving this issue? Thanks, Tom

01/16/2013 20:53 Oleg Fomin wrote:

Ian, Tom, Yes, I am working around this problem. As it turned out, this is due Microsoft RTF control used to render multi-line text in FRB. When I just omit it - all works fine without memory leakage. Thank you for your patience. Best regards, --- Oleg Fomin <oleg@fomin.info>

01/17/2013 01:28 Tom H. wrote:

Oleg, I poked around the TPS report file for one of our problem reports, and didn't see anything that indicates the type of control (object) to be created. What determines whether an RTF or simple string is created by FRB? Is it something like the SplitEnable flag? We are coming up on deadlines and really need a workaround. If I can alter the RPT file to not create RTF controls, that would be a real help. Thanks, Tom

01/17/2013 01:41 Oleg Fomin wrote:

> What determines whether an RTF or simple string is created by FRB? > Is it something like the SplitEnable flag? Yes. Exactly.

01/17/2013 19:07 Tom H. wrote:

Thanks -- I can confirm that removing all SplitEnable flags did stop the memory leaks. Tom

02/15/2013 00:26 Ian Cook wrote:

I assume the SplitEnable flag refers to the multi line text and auto resize options for a frame. If so then that is not really a workable solution for me as I use it all the time. Are there any other solutions please? Ian