January 2002 - Libsmi - lists.ibr.cs.tu-bs.de

Re: [libsmi] memory leak; program terminates
by Dave Shield 15 Jan '02

15 Jan '02

> There are good reasons for the parser to terminate in case of severe > errors. If it would continue, you would end up with dangling pointers > and consequences you would not like! ;-) Sure - it's sensible for the parser to terminate - perhaps setting a flag so that any further attempt to use the library routines would fail. But it's a stage more drastic to issue an "exit" - so that the whole application will terminate immediately. It's then got no chance to tidy up and save any internal state, pop up a dialog box to report the error back to the user, offer to work with numeric OIDs instead, or however else the programmer wishes to handle this. > So: First fix the first module before running your application with > the next one. That's (unnecessarily) restricting the application IMO. What if the application was a batch-mode SMI validator - whose whole *purpose* was to report back errors in the module - perhaps running as a network service? Is it really sensible for it to exit completely when it comes across a corrupt MIB? A library is perfectly entitled to signal a serious error, and refuse to proceed. But it shouldn't take it upon itself to terminate the whole application. Dave -- !! 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(a)ibr.cs.tu-bs.de>. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.

3 2

RE: [libsmi] memory leak; program terminates
by Arie Trost 15 Jan '02

15 Jan '02

Hi Kang, Thanks for the tip, this did the trick. I've noticed that exit(-1) statement in printError(). I would like my application to skip a MIB module that caused a failure and continue loading other MIBs. How can I handle this situation in my application (do some cleanup for a falty MIB and prepare for loading the next one)? Thank you, Arie. > -----Original Message----- > From: Kang, Jeongwon [mailto:hanule@3ic.co.kr] > Sent: Friday, January 11, 2002 11:25 PM > To: Arie Trost > Cc: libsmi(a)ibr.cs.tu-bs.de > Subject: Re: [libsmi] memory leak; program terminates > > > Hi Arie, > > I looked into your code and libsmi code. > > Your mib file "HCNUM-TC.txt" required SNMPv2-SMI and SNMPv2-TC. > Libsmi lookup nothing because of illegal mib path, > so parser occured internal error. > exit(-1) was called at printError() in error.c. > To call smiExit() was omitted. > > The memory leak problem of your program owed to omitting > smiExit() more than libsmi. > > > Add smiSetPath(). > Then No Error. > > STDMETHODIMP CGMIBAccessor::Initialize() > { > ... > smiSetPath(your_mib_file_path); // addition requred > ... > return S_OK; > } > > > Best regards, > Jeongwon. > -- !! 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(a)ibr.cs.tu-bs.de>. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.

3 2

Status of SMI DTD v0.1
by Frank.Fock＠t-online.de 15 Jan '02

15 Jan '02

Hello Frank & Juergen, I have implemented the SMI DTD v0.1 (which has expired for quite a while now) for my MIB Explorer product. Similar to smidump it can dump MIBs as XML. MIB Explorer supports SMIv1 and SMIv2 formats. SMIng is not supported. An example XML output can be found at http://www.mibexplorer.com/features/SNMP-NOTIFICATION-MIB.xml What are the plans about an update of the SMI DTD draft? Any chance to advance this to a standard? I did not encounter any problems with the DTD during implementation, however I recognized that smidump seems to violate the DTD regarding CDATA generation (for example the description element). As more and more people are using XML in the network management area, I think it could be useful to advance the SMI DTD draft. Best regards, Frank Fock -- !! 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(a)ibr.cs.tu-bs.de>. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.

3 5

Re: [libsmi] memory leak; program terminates
by Kang, Jeongwon 12 Jan '02

12 Jan '02

Hi Arie, I looked into your code and libsmi code. Your mib file "HCNUM-TC.txt" required SNMPv2-SMI and SNMPv2-TC. Libsmi lookup nothing because of illegal mib path, so parser occured internal error. exit(-1) was called at printError() in error.c. To call smiExit() was omitted. The memory leak problem of your program owed to omitting smiExit() more than libsmi. Add smiSetPath(). Then No Error. STDMETHODIMP CGMIBAccessor::Initialize() { ... smiSetPath(your_mib_file_path); // addition requred ... return S_OK; } Best regards, Jeongwon. ----- Original Message ----- From: "Arie Trost" <ariet(a)genesyslab.com> To: "'Frank Strauss'" <strauss(a)ibr.cs.tu-bs.de>; "Kang, Jeongwon" <hanule(a)3ic.co.kr> Cc: <libsmi(a)ibr.cs.tu-bs.de> Sent: Saturday, January 12, 2002 11:44 AM Subject: RE: [libsmi] memory leak; program terminates > Hi, > > Although I could think of some workarounds for my specific problem, I > believe > it would be nice to have libsmi working flawlessly in those > long-term-process scenarios (e.g., a COM/ActiveX object, a regular DLL, > etc). > > Having the capability of launching parsing tools from, for example, > an HTML page, will give some new perspective to libsmi.. > > My humble contribution to that: > Attached please find a zip file containing a sample Visual C++ project > that demonstrates the crash I had been experiencing with my COM object. > Once you've unzipped the files and built the project, you can instantly > start using it for debugging libsmi while it's used from within a COM > component. > > Instructions: > > 1. Unzip the file, for example, onto a folder c:\libsmi-com > Three sub-folders will be created under c:\libsmi-com: > > Mibcom - contains the COM server dll project > client - a simple COM client application project > libsmi-win32 - libsmi built as a static win32 multithreaded library > (used by Mibcom) > > 2. Open Visual project c:\libsmi-com\Mibcom\MIBCOM.dsw > (workspace will contain both projects, that one for COM server and > COM client.) > > Build the both projects and run the test. > > 3. Once you've run the test, the client will start consequently > loading MIB files (from c:\libsmi-com\client\mibs). > You will see that after fourth ot fifth call to LoadMIB() or so, the > client will > crash. > > 4. You can debug the program by setting up break-points in test.cpp (in > order to > trace the client) and setting DebugBreak() in GMIBAccessor.cpp in order > to trace > the server (including to break into the libsmi's code.). See the > CGMIBAccessor::LoadMIB() function. > > 5. Project can be used under Windows NT 4.0, Windows 2000 and Windows XP. > > Hope this will help to resolve the issue (hopefully someone out there among > the > libsm maintainers will take a shot at it). > > Best regards, > 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(a)ibr.cs.tu-bs.de>. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.

1 0

RE: [libsmi] memory leak; program terminates
by Arie Trost 11 Jan '02

11 Jan '02

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(a)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(a)ibr.cs.tu-bs.de>. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.

3 2

RE: [libsmi] memory leak; program terminates
by Arie Trost 10 Jan '02

10 Jan '02

smiExit() was meant to be called at the time my COM object is released by the client, not before that, as I want the libsmi structures to persist as long as the object is alive. In my case, the program is terminating at step 2, when it is doing some work (loading MIB files in).. Arie. > -----Original Message----- > From: Kang, Jeongwon [mailto:hanule@3ic.co.kr] > Sent: Wednesday, January 09, 2002 10:17 PM > To: Arie Trost > Cc: libsmi(a)ibr.cs.tu-bs.de > Subject: Re: [libsmi] memory leak; program terminates > > > 1) smiInit() > 2) some work > 3) smiExit() > > I assume that you omitted smiExit(). > > > -- !! 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(a)ibr.cs.tu-bs.de>. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.

1 0

memory leak; program terminates
by Arie Trost 10 Jan '02

10 Jan '02

Hi, I have been trying to add a MIB parsing capability to my COM object. To get started with libsmi, I have implemented this very simple thing: 1) Add a method on a COM interface that would merely load MIB modules, like so: STDMETHOD CSomeCOClass::LoadMIB(BSTR MIBFileName) { char *modulename; char szFileName[MAX_PATH]; WideCharToMultiByte(CP_ACP, 0, MIBFileName, -1, szFileName, MAX_PATH, NULL, NULL); modulename = smiLoadModule( szFileName); return S_OK; } 2) Add a call to smiInit() from within the object's initialisation method. 3) Now, a COM client application is performing a series of calls to the method presented above (LoadMIB), each time passing to it a different MIB module (some standard RFC modules). (A note: the next step would be of course to use further libsmi's APIs to provide actual parsing for the pre-loaded MIBs, but at this time I have been trying to realize whether I can successfully load a decent number of MIB modules.) The problem is that at some point, after (what seems to be a successful) loading of several MIB files, Visual C++ warns on memory leak and the program is terminated. My question is, am I missing something in the sample above, is there any other libsmi API that should have been called in addition to smiInit() and smiLoadMOdule() to make it properly load MIB files? Thanks, 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(a)ibr.cs.tu-bs.de>. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.

3 2

Another Segmentation fault
by Kang, Jeongwon 09 Jan '02

09 Jan '02

Thanks! libsmi-cvs-20020109 Window 2000/cygwin/gcc-3.0.3 $ smidump.exe IUX_MIB.my IUX_MIB.my:7: parse error, unexpected `INTEGER' smidump: module `IUX_MIB.my' contains errors, expect flawed output // // This module has been generated by smidump 0.3.0. Do not edit. // module IUX-MIB { Segmentation fault (core dumped) 1 IUX-MIB DEFINITIONS::= BEGIN 2 3 IMPORTS 4 enterprises FROM RFC1155-SMI 5 DisplayString FROM RFC1213-MIB 6 MODULE-IDENTITY, OBJECT-TYPE, 7 Counter, INTEGER, OBJECT-IDENTITY, 8 IpAddress, TimeTicks FROM SNMPv2-SMI; 9 10 ntels OBJECT IDENTIFIER ::= { enterprises 9608 } ... Removing INTEGER made no problem. Only smidump crashed. $ smilint IUX_MIB.my IUX_MIB.my:7: parse error, unexpected `INTEGER' $ gdb (gdb) file smidump (gdb) run IUX_MIB.my Starting program: /usr/local/bin/smidump.exe IUX_MIB.my Program received signal SIGSEGV, Segmentation fault. 0x00403176 in createImportList (smiModule=0xa016b08) at dump-sming.c:386 (gdb) bt #0 0x00403176 in createImportList (smiModule=0xa016b08) at dump-sming.c:386 #1 0x00403aee in fprintImports (f=0x6109925c, smiModule=0xa016b08) at dump-sming.c:622 #2 0x00405629 in dumpSming (modc=1, modv=0xa012688, flags=0, output=0x0) at dump-sming.c:1270 #3 0x00401e60 in main (argc=2, argv=0xa0117c0) at smidump.c:333 ... -- !! 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(a)ibr.cs.tu-bs.de>. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.

3 2

Segmentation fault
by 강정원 09 Jan '02

09 Jan '02

libsmi-0.3.0 cygwin/VC++ 6.0 sp5 $ smilint IPMS-MIB.my ... IPMS-MIB.my:1328: identifier `ipms_traps' must not contain an underscore IPMS-MIB.my:1329: `DisplayString' should start with a lower case letter Segmentation fault (core dumped) Also smiquery and smidump does crash! IPMS-MIB.my ... 1326 1327 ipmsTrapServiceStart TRAP-TYPE 1328 ENTERPRISE ipms_traps 1329 VARIABLES { DisplayString } 1330 DESCRIPTION 1331 "This trap is generated when a ipms service started" 1332 ::= 1 1333 ... I assumed that 1329 line cause smilint crashed. Removing 1329 line or replacing that with "VARIABLES { some object-type } " make no segmentation fault. -- VC Call stack -- smiparse() line 4184 + 5 bytes loadModule(const char * 0x0096a481) line 3789 + 9 bytes smiLoadModule(const char * 0x0096a481) line 418 + 9 bytes data.c ... 3659 smiDepth++; 3660 parser.line = 1; 3661 smiparse((void *)&parser); <-- this point 3662 smiLeaveLexRecursion(); 3663 smiDepth--; 3664 fclose(parser.file); ... I know that IPMS-MIB.my has illegal VARIABLES clause. I wish NOT crash BUT warn or error Please, help me. -- !! 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(a)ibr.cs.tu-bs.de>. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.

2 1