smilib: memory leaks?

Hi,
I am using libsmi in a Win32 project. I have troubles to compile the last version of the SVN depot (but I can compile the last release package 0.4.8). When do you plan to officially release a new version of libsmi?
Furthermore, I am suspecting memory leaks in the libsmi code.
o smiInit()
o Use of smi calls to load a MIB file and do my job
o smiExit()
There are still memory blocks not released probably allocated by smilib.
I would like to add a module to smilib to track memory usages and dump memory blocks not released at the end. The main problem I see in the current code is that there is no central point to manage malloc(), free() and others.
What do you think of it?
o Should I create my own module for this purpose and uses it for my own usage and that's all?
o Or do you think it could be a good idea to add such a module into the official branch of libsmi?
Any feedback is welcome :-)
Raymond

On Wed, Mar 24, 2010 at 09:14:42PM +0100, Raymond Mercier wrote:
I am using libsmi in a Win32 project. I have troubles to compile the last version of the SVN depot (but I can compile the last release package 0.4.8). When do you plan to officially release a new version of libsmi?
No clue. But if you have problems, please send patches or at least detailed descriptions of the problem to this list.
Furthermore, I am suspecting memory leaks in the libsmi code.
o smiInit() o Use of smi calls to load a MIB file and do my job o smiExit()
There are still memory blocks not released probably allocated by smilib.
I would like to add a module to smilib to track memory usages and dump memory blocks not released at the end. The main problem I see in the current code is that there is no central point to manage malloc(), free() and others.
Look at smi.h - there are some (perhaps old) hooks for dmalloc.
What do you think of it?
o Should I create my own module for this purpose and uses it for my own usage and that's all?
o Or do you think it could be a good idea to add such a module into the official branch of libsmi?
I prefer to keep the library clean from debugging code. There are different tools to track memory leaks and it is great if people use the tools they prefer to create patches that fix memory leaks. I am not so keen on adding memory debugging infrastructure to the library itself.
/js
participants (2)
-
Juergen Schoenwaelder
-
Raymond Mercier