|| | |||Browse by category|
http://www.kbpublisher.com - http://www.kbpublisher.com
[b]text[/b] - Bold text.
[u]text[/u] - Underline text.
[i]text[/i] - Italic text.
[color=green]text[/color] - Colored text.
[url]kbpublisher.com[/url] - kbpublisher.com
[url=kbpublisher.com]text[/url] - text
[email]email@example.com[/email] - firstname.lastname@example.org
[h1]text[/h1] - Caption text.
- item 1
- item 2
- item 1
- item 2
My memory checker shows memory leaks in the Rogue Wave Tools.h++ code.
We are often asked about memory leaks in the Tools.h++ libraries, frequently by users who have had memory leaks reported by tracing or debugging utilities. Memory leaks are an important consideration for developers and the technical issues here can be somewhat complex. What is most important for the developer to know is that we thoroughly test the library code in an effort to make sure it has no memory leaks.
The libraries use static allocations, including a form of memory caching, which some unsophisticated utilities may report as a memory leak. These are NOT memory leaks. A memory leak typically occurs when new'ed memory is not deleted, resulting in a continual loss of available heap space. The memory used by the Tools.h++ static allocations is very limited (typically less than 200 bytes), is allocated only once, and is returned to the operating system when the application terminates.
If the user requires a complete and accurate assessment of memory usage, we recommend a professional product such as Purify. Commonly available utilities may give incomplete, misleading, or incorrect results.
There are three common sources for these types of reports: system specific information such as RWZone and RWLocale, the RWFactory object, and a memory cache used by most of our collections called RWMemoryPool.
Information about a system's time zone and locale is very expensive to calculate. Because of this we do not calculate this information until the first time the program tries to use it, and then we keep a pointer to this information around so we don't have to recalculate it. This saved information may show up as a memory leak.
The RWFactory object is used to keep track of all the RWCollectable objects used within a program. This is accomplished by having a static initialize for each RWCollectable insert an entry into the RWFactory. Because the RWFactory is a global object that could be accessed at any time we can not remove it from memory until the program terminates. Because of this some memory checkers may record the RWFactory and each of the entries inserted into it (one for each RWCollectable class used by the program) as a leak.
The RWMemoryPool is a way of increasing the speed of collections that allocate and deallocate lots of small objects, such as the individual nodes of a linked list. It accomplishes this by keeping around a small number of allocations of a known size and reusing them rather than returning them to the operating system. By default the number of allocations cached is 5 each of sizes 2,4,6,8, and 10 bytes. Using these number the most that will be cached is 150 bytes in 25 allocations. Most programs will use much less.
The RWMemoryPool caching can be turned off using the following method. This method will have performance penalties and will not eliminate the other types of allocations. This technique applies to Tools.h++ v6.0.0 - v6.1.0. To turn caching off, change the following line in mempool.h (near the end of the file) from:
Then rebuild the library and the application with RW_NO_CACHE defined.#ifdef RW_MULTI_THREAD
#if defined(RW_MULTI_THREAD) || defined(RW_NO_CACHE)