RE: [libsmi] Re: MIB load limit

For anyone who's interested in my experience:

With no knowledge of SNMP, I just started working on some SNMP code about 6 months ago. After reading the "SNMP MIB Handbook" by Larry Walsh, right from the start I used the "web interface to libsmi" at severity level 6 to check my MIBs. Initially it was a bit depressing how many errors and warnings were reported, however, each one either showed a gap in my understanding, a real error or an improvement that could be made in my MIB.

The most important thing I've learnt in over 30 years of programming is to always select the strictest level of checking in all the compilers I use, and always treat warnings (and informationals) as errors. I now never start debugging until the compiler output is completely clean. Doing this takes me an extra few hours up front in all my developments but I estimate it saves at least 10 times as many frustrating hours of debugging.

So don't be impatient, use all the tools you have available to try to perfect your code BEFORE you start debugging it!

Tony Hicks Senior Software Engineer CA Orchestria

anthony.hicks@ca.com www.orchestria.com

-----Original Message----- From: libsmi-bounces@ibr.cs.tu-bs.de [mailto:libsmi-bounces@ibr.cs.tu-bs.de] On Behalf Of Miroslav Beranic ml. Sent: 21 February 2009 20:13 To: libsmi@ibr.cs.tu-bs.de Subject: [libsmi] Re: MIB load limit

Hi,

I guess practise makes perfect, stands.

It turned out that libSMI's internal error-handler is not just for fun. I was not catching errors reported by this nifty utility. The problem was, I was missing dependent MIB files, and forces libSMI to raise SIGSEGV, when I ignored reported messages earlier.

So: use internal error-handler... It will save you great deal of headaches and time.

Regards, Miroslav Beranič ml.

2009/2/21 Miroslav Beranič ml. miroslav.beranic@gmail.com:

Hi,

I am trying to load multiple MIB files (about 50 of them) in one process. I get a segment fault when calling method

extern SmiNode *smiGetFirstNode(SmiModule *smiModulePtr, SmiNodekind nodekind);

I managed to trace it to method

static Object *getNextChildObject(Node *startNodePtr, Module *modulePtr, SmiNodekind nodekind)

in smi.c:159 (in TRUNK)

There is an if statement:

       if (((!modulePtr) || (objectPtr->modulePtr == modulePtr)) &&
           ((nodekind == SMI_NODEKIND_ANY) ||
            (nodekind & objectPtr->export.nodekind))) {
           break;
       }

Statement: objectPtr->export

seems to point to invalid memory address. As I debuged it looks like properties

• export
• flags
• line

point to invalid memory, as by accessing it, it signals SIGSEGV.

So my question: Is there any limit on loading MIBs or any other reason this can happen? And next: what would be good way to load multiple MIB-s -- lets say any MIB in specific directory... description of how to do this or some pointers would be great.

Best regards, Miroslav Beranič ml.