Unexplained SNMP crash during startup...

[Dave Mason]

Hi,
This looks like the inverse parallel universe version of the crash I 
described in my "persistence database causes crash" thread.  I have a 
frequent problem where I can start the agent fine, but I have an array 
of trap varbinds that I use repeatedly (sandbox fashion), and sometimes 
on the second or third iteration through my code, it crashes in a 
destructor.  It's trying to replace an old value with a new one.  I 
looked through the code backwards and forwards and could never see 
anything wrong - the best clue I found is that the crash only happens 
after loading a persistence database.  If the agent starts with no 
persistence files it works fine.  FYI - I have a single CPU PC running 
Red Hat 7.2.  I added mutexes around any user code that does persistent 
saves but it didnt help.

I never thought of commenting out all my code.  I use a subclass of 
MibLeaf as Nick does, with some extra attributes that are not in 
MibLeaf.  Will those cause an error if I try to load them into a MibLeaf 
object?  (I'd try it now but I'm off on something else...)

Regards,
Dave

Ram Krishnaswamy wrote:

>Hi Nick,
>
>I have run into similar crashes on solaris 2.8 running more than one
>processor. What you can try to do is comment out all your code and run the
>agent. If it does not crash then there is a problem with your code -
>basically thread problems. 
>
>Other thing you can try is to bind your agent process to a specific
>processor using pbind. It is available on Solaris. I do not know whether it
>is available on other Unix OS'es. 
>
>HTH.
>
>Ram
>-----Original Message-----
>From: Nick Woods
>To: agentpp-dl____agentpp.com
>Sent: 11/8/2002 5:44 PM
>Subject: Unexplained SNMP crash during startup...
>
>For the past month I have been running into some intermittent crashes
>(sig 11's) during the startup of my system and mib entry creation.  The
>following is a backtrace from my program.  I was getting some different
>backtraces for a while but it now consistently seems to have this one
>problem.  I have a class derived from Agentpp::MibLeaf that is being
>created here.  It often works but will crash when the system seems to
>get a little more active.  This never seems to be a problem after a
>fresh reboot with no one else on the machine.  This is also a dual CPU
>machine running Linux so it can make context switch threading bugs more
>apparent.  Is there any state that I need to protect with a mutex when
>creating these objects or making any agent++ calls?  Has anyone else run
>into anything similar?  I have also tried increasing my thread stack
>size AGENTPP_DEFAULT_STACKSIZE to 150000 to see if it would help but it
>did not.  I turned on all of the agent++ logging but it gave me no more
>useful information.  I never seemed to have this problem before thread
>support was added to agent++ and have made no code changes since
>upgrading so I'm wondering if there is a possible race condition that I
>am exposing, or something else I need to be aware of regarding the
>threads in the system.  I am currently running agent++v3.5.6, and
>snmp++v3.2.1b.  Any help would be much appreciated.  
>
>#0  0x40a5fb11 in __kill () at __kill:-1
>#1  0x4084679b in raise (sig=6) at signals.c:65
>#2  0x40a61092 in abort () at ../sysdeps/generic/abort.c:88
>#3  0x0805e2a6 in signalHandler (signo=11) at test.cxx:551
>#4  0x40846b53 in pthread_sighandler_rt (signo=11, si=0xbfffe070,
>uc=0xbfffe0f0) at signals.c:121
>#5  <signal handler called>
>#6  chunk_alloc (ar_ptr=0x40b66300, nb=49) at malloc.c:2993
>#7  0x40ab1828 in __libc_malloc (bytes=40) at malloc.c:2811
>#8  0x409f215d in __builtin_new (sz=40) at ../../gcc/cp/new1.cc:-1
>#9  0x409f22a0 in __builtin_vec_new (sz=40) at ../../gcc/cp/new2.cc:-1
>#10 0x4098a543 in Oid::Oid (this=0x80909c8, oid=@0xbfffe650) at
>oid.cpp:132
>#11 0x4085c84f in Agentpp::Oidx::Oidx (this=0x80909c8,
>_ctor_arg=@0xbfffe650) from
>/home/test/dev/wa/cache/publish/lib/libpvmonitor.so
>#12 0x408cd32b in Agentpp::MibEntry::MibEntry (this=0x80909a0,
>o=@0xbfffe650, a=READONLY) at mib_entry.cpp:128
>#13 0x408b61a8 in Agentpp::MibLeaf::MibLeaf (this=0x80909a0,
>o=@0xbfffe650, a=READONLY, s=66) at mib.cpp:134
>
>I have stepped through this code and the original calls to create the
>Oid (a static string) look fine but it seems like some of the values
>might be corrupted by the end although I am not 100% sure.
>
>Thanks,
>
>Nick
>