RE: [libsmi] memory leak; program terminates
Hi Frank,
I've tracked down the crash to the point where the loadModule() function calls to yyparse.
When running my test program outside Microsoft Visual C++, I don't see any warning or error messages at all, the program just terminates But when running in Visual C++ debugger, I am getting messages like these (a snippet) at the time of a crash:
Detected memory leaks! Dumping objects -> {6846} normal block at 0x026C1948, 1258 bytes long. Data: <The CounterBased> 54 68 65 20 43 6F 75 6E 74 65 72 42 61 73 65 64 {6844} normal block at 0x01C2FFE0, 20 bytes long. Data: <CounterBasedGaug> 43 6F 75 6E 74 65 72 42 61 73 65 64 47 61 75 67 {6843} normal block at 0x01C2E050, 44 bytes long. Data: <N > 4E 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 ... ...
Actually, as you will see, there is memory leak after each call to smiLoadModule()! There are several articles at MSDN describing how to detect memory leaks in Visual C++ runtime system. One way to do this is to dump memory leak information at the points of interest in the code using the _CrtDumpMemoryLeaks() function.
So, calling _CrtDumpMemoryLeaks() after smiLoadModule() will produce memory leak warning (similar to that above). The same happens in smidump (which I've built in a separate Visual C++ project). However, it's only my DLL that would crash, not smidump :(
Any hints how one could better trace the parsing process (debug the Bison parser and the relevant components within the libsmi itself). Any other suggestions?
Thank you. Arie.
-----Original Message----- From: Frank Strauss [mailto:strauss@ibr.cs.tu-bs.de] Sent: Wednesday, January 09, 2002 11:28 PM To: Arie Trost Cc: libsmi@ibr.cs.tu-bs.de Subject: Re: [libsmi] memory leak; program terminates
Hi Arie!
What you have done so far (smiInit() and several calls to smiLoadModule()) is correct. I don't know how C++ runtime systems behave with respect to memory leaks. I cannot guarantee that there are no more leaks in the libsmi code (in fact, I'm quite sure that there are still some minor leaks not yet fixed). But I wonder why your runtime system terminates the program for this reason.
-frank
-- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to libsmi-request@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
Hi Arie.
I have performed two project with libsmi during six months. The libsmi was not fault-tolerable. At loadModule() and smiExit(), access violation error occured occasionally, so exception handling must be done. For loadModule() error occured by bad mib file and for smiExit() i don't know.
I recommend following exception handling.
SmiModule* smiModule; try { char* name = smiLoadModule(moduleName.c_str()); smiModule = name ? smiGetModule(name) : NULL; } catch(...) { ... try{ smiExit(); } catch(...) { ... } ... }
Termination is serious more than memory leak?
----- Original Message ----- From: "Arie Trost" ariet@genesyslab.com To: "'Frank Strauss'" strauss@ibr.cs.tu-bs.de Cc: libsmi@ibr.cs.tu-bs.de Sent: Friday, January 11, 2002 8:30 AM Subject: RE: [libsmi] memory leak; program terminates
Hi Frank,
I've tracked down the crash to the point where the loadModule() function calls to yyparse.
When running my test program outside Microsoft Visual C++, I don't see any warning or error messages at all, the program just terminates But when running in Visual C++ debugger, I am getting messages like these (a snippet) at the time of a crash:
Detected memory leaks! Dumping objects -> {6846} normal block at 0x026C1948, 1258 bytes long. Data: <The CounterBased> 54 68 65 20 43 6F 75 6E 74 65 72 42 61 73 65 64 {6844} normal block at 0x01C2FFE0, 20 bytes long. Data: <CounterBasedGaug> 43 6F 75 6E 74 65 72 42 61 73 65 64 47 61 75 67 {6843} normal block at 0x01C2E050, 44 bytes long. Data: <N > 4E 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 ... ...
Actually, as you will see, there is memory leak after each call to smiLoadModule()! There are several articles at MSDN describing how to detect memory leaks in Visual C++ runtime system. One way to do this is to dump memory leak information at the points of interest in the code using the _CrtDumpMemoryLeaks() function.
So, calling _CrtDumpMemoryLeaks() after smiLoadModule() will produce memory leak warning (similar to that above). The same happens in smidump (which I've built in a separate Visual C++ project). However, it's only my DLL that would crash, not smidump :(
Any hints how one could better trace the parsing process (debug the Bison parser and the relevant components within the libsmi itself). Any other suggestions?
Thank you. Arie.
-- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to libsmi-request@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
Hi!
Arie> Any hints how one could better trace the parsing process (debug Arie> the Bison parser and the relevant components within the libsmi Arie> itself). Any other suggestions?
Kang> [...] I recommend following exception handling. [...]
Arie's problem is due to memory leaks in the libsmi code. The exact reasons cannot be identified and fixed by wrapping exception handling around the libsmi calls.
Some time ago, I fixed most of the more costly leaks using Purify and dmalloc. Bill Fenner also helped a lot in fixing leaks. But, when I came to a point where I lost oversight and only minor leaks were left, I gave up, since the commonly used programs (smilint, smidump) are just oneshot tools; there were no long term processes so far where memory consumption significantly matters. (Sorry for that bad excuse! ;-))
-frank -- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to libsmi-request@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
participants (3)
-
Arie Trost -
Frank Strauss -
Kang, Jeongwon