[Date Prev][Date Next]
[Thread Prev][Thread Next]
[Date Index]
[Thread Index]
[New search]
To: "Mitchell, Sue" <Sue.Mitchell@xxxxxxxxxx>, "Framers (E-mail)" <framers@xxxxxxxxx>
Subject: Re: Debug versus Release mode in Visual C++ and FDK
From: DW Emory <danemory@xxxxxxxxxxxxxxxxxx>
Date: Thu, 27 Nov 2003 12:30:10 -0800
Cc: framers@xxxxxxxxxxxxxx (Framers List)
In-Reply-To: <200311271805.hARI5uP8018411@omsys.com>
Sender: owner-framers@xxxxxxxxx
NOTE: This message has also been cross-posted to the Framers list. ================================================= I have no direct answer to your problem. But I can tell you this: FrameMaker, particularly when working with structured docs, is very possibly the ultimate memory leak offender. Even (as I do) I turn on Automatic Save every 5 minutes under Preferences, and use a product called FreeMem to periodically force the deallocation of unused memory during a FrameMaker session, the leakage accumulates rapidly, even in a structured doc that is less than 10 pages. If you have Norton System Doctor, and set it up to continuously monitor the total amount of available allocated memory, the amount of available physical memory, and the amount of available physical memory Cache on a Windows platform, you can see the leakage accumulate as the FrameMaker session continues. Using a product like FreeMem gets some of it back at the end of the session, but by no means all of it. That, apparently, is because, even after closing FrameMaker, that leaked memory is still marked as being allocated. The only way to get rid of it is to shut down Windows. By recording the values of those 3 Norton System Doctor parameters before you start a long and intensive FrameMaker structured document session (with no other program running), and then comparing those values with the ones displayed following the exit from FrameMaker, you can calculate the magnitude of the cumulative residual memory leak. It is huge--much larger, for instance, than that produced during a Word session, even though that piece of crap typically uses a much greater amount of memory than FrameMaker. Another thing I've noticed is that, if I leave FrameMaker running when I get interrupted in the middle of an editing session, and then go back several hours later, the memory leakage has continued to grow substantially in the interim, and the amount of leakage recoverable with FreeMem in that case is reduced substantially. At 12:43 PM 11/27/03 -0500, Mitchell, Sue wrote: >I am hoping that there are some experienced C/C++ programmers out there who >can help me ... > >We have been experiencing some problems using Visual C++ to debug a >Structured Application that we are creating to handle the import and export >of XML files. If the dll is compiled using debug mode, Frame crashes at one >or more memory release points (using either free or one of Frame's build in >memory handlers such as F_ApiDeallocateAttributes). If the dll is compiled >using release mode it does not. > >We have now set up our environment to allow us to debug in release mode but >that doesn't really deal with the issue of why one mode crashes and the >other doesn't. Our concern is that there are in fact memory leaks happening >but that in the release mode they are not being caught somehow? Is any of >this possible? FrameMaker/FrameMaker+SGML Document Design & Database Publishing DW Emory <danemory@globalcrossing.net> ** To unsubscribe, send a message to majordomo@omsys.com ** ** with "unsubscribe framers" (no quotes) in the body. **