varbind management/construction problem

[Dave Mason]

Hi Frank,
MAX_PDUSIZE is 9, since I have 9 varbinds.  I can try increasing it by 
one, but I would be surprised if that made a difference.  That thread 
doesnt have anything else going on besides building traps, so it's 
pretty minimal as it is.  I'm not sure how another method could have a 
side effect - one thing I can try is build the PDU inline instead of 
calling another method.  Maybe something is getting stepped on when I 
make the call.  When in doubt, I guess the thing to do is pull out stuff 
till it works, then put it back in and see where it goes wrong.

Thanks for having a look - I wanted to make sure I wasn't doing anything 
undefined.

Dave

Frank Fock wrote:

> Hi Dave,
>
> Is the constant MAX_PDUSIZE > 1? If this is OK, it seems
> that some other method has a bad side effect on your
> memory. Then your only chance is to reduce the code to
> a minimum to see if it still crashes.
>
> Hope this helps.
>
> Best regards,
> Frank
>
>
> Dave Mason wrote:
>
>> Oops - I just noticed I left out a } when I typed my last mail.  The 
>> first version of my run method should look like this:
>>
>> void
>> ttiTrapThread::run()
>> {
>>  Vbx* vbs = new Vbx[MAX_PDUSIZE];
>>  while (running) {
>>    event.wait();
>>    switch (event.type()) {
>>    case COMMS_ALARM:
>>      buildAlarmVb(event, vbs, seqNum);  // build varbinds
>>      commsAlarm.generate(vbs, ALARM_PDUSIZE, ""); // send trap
>>      activateAlarm(event, vbs, seqNum);  // write to active alarm table
>>      break:
>>    case ....
>>    }
>>  }
>>  delete [] vbs;
>> }
>>
>> Later I moved the new/delete inside the while loop but I still get a 
>> crash.  I do appreciate your help with this.
>>
>> Dave
>>
>> Dave Mason wrote:
>>
>>> Hi all,
>>> This is probably some type of C++ programming problem.  I hesitated 
>>> to send it to the mailing list, but I've been stuck on it for a 
>>> while, so I thought I'd try my luck.
>>>
>>> I have a thread that I start from main() right before the request 
>>> processing loop that handles asynchronous events.  It receives them 
>>> from the backend, builds a PDU, sends the trap, and goes back to 
>>> wait for another event.  The problem I have is that everything works 
>>> fine for the first event, but it crashes on the second one.  It's 
>>> got to be some kind of memory management problem but I havent found 
>>> it yet.  I thought I'd send this in case anybody sees that I'm using 
>>> the methods wrong.  I have Agent++ version 3.5.3a and Snmp++ version 
>>> 3.1.6c.  Maybe a little old, but I dont remember anything in the new 
>>> change logs that relates to this.  gcc is version 2.96.
>>>
>>> I made two attempts.  For the first, I allocate the varbind memory 
>>> once, reuse the structure each time through the loop, and delete the 
>>> whole Vbx array at the end.  Here's a quick snapshot of the code:
>>>
>>> void
>>> ttiTrapThread::run()
>>> {
>>>  Vbx* vbs = new Vbx[MAX_PDUSIZE];
>>>  while (running) {
>>>    event.wait();
>>>    switch (event.type()) {
>>>    case COMMS_ALARM:
>>>      buildAlarmVb(event, vbs, seqNum);  // build varbinds
>>>      commsAlarm.generate(vbs, ALARM_PDUSIZE, ""); // send trap
>>>      activateAlarm(event, vbs, seqNum);  // write to active alarm table
>>>      break:
>>>    case ....
>>>    }
>>>  delete [] vbs;
>>> }
>>>
>>> void
>>> ttiTrapThread::buildAlarmVb(event, Vbx* vbs, unsigned long seqNum)
>>> {
>>>  string oid;
>>>  int    n=0;
>>>
>>>  // determine oid and value
>>>  vbs[n  ].set_oid(oid.c_str());
>>>  vbs[n++].set_value(value);
>>>
>>>  // add more varbinds as needed
>>> }
>>>
>>> void
>>> ttiTrapThread::activateAlarm(...)
>>> {
>>>  // MibTableRow* row = tableEntry::instance->add_row(indexOID)
>>>  // call vbs[n].get_value(..) to get values for alarm table
>>>  // call tableEntry::instance->set_row(row, ...) to add values to 
>>> alarm table
>>> }
>>>
>>> I checked the Vbx methods, and they all appear to delete the OID and 
>>> value if the vb is reassigned, so this looked OK.  The problem 
>>> occurs when the second event arrives.  Vb::set_oid gets called to 
>>> set the new OID, and the crash happens at the delete for the old 
>>> OID.  The crash looks like this:
>>>
>>> (gdb) where
>>> #0  0x40410e46 in chunk_free (ar_ptr=0x404c4620, p=0x80d3998) at 
>>> malloc.c:3242
>>> #1  0x40410bf4 in __libc_free (mem=0x80d39a0) at malloc.c:3154
>>> #2  0x4027a1f6 in __builtin_delete (ptr=0x80d39a0) from 
>>> /usr/lib/libstdc++-libc6.2-2.so.3
>>> #3  0x4027a21f in __builtin_vec_delete (ptr=0x80d39a0) from 
>>> /usr/lib/libstdc++-libc6.2-2.so.3
>>> #4  0x40369d60 in Oid::operator= (this=0x80d0bb8, oid=@0x4094b8cc) 
>>> at oid.cpp:217
>>> #5  0x4036ef33 in Vb::set_oid (this=0x80d0bb8, oid=0x4094b8cc) at 
>>> vb.cpp:151
>>> #6  0x08057dab in Agentpp::ttiTrapThread::buildAlarmVb (this=0x0, 
>>> nmEv=@0x4094ba0c, vbs=0x80d0b48, seqNum=1) at ttiTrapThread.cpp:215
>>> #7  0x08057331 in Agentpp::ttiTrapThread::run (this=0x80d2e10) at 
>>> ttiTrapThread.cpp:139
>>> #8  0x402eb315 in Agentpp::TaskManager::run (this=0x80d3110) at 
>>> threads.cpp:724
>>> #9  0x402e9f40 in Agentpp::thread_starter (t=0x80d3138) at 
>>> threads.cpp:472
>>> #10 0x40244b9c in pthread_start_thread (arg=0x4094bbe0) at 
>>> manager.c:274
>>> #11 0x40244c7f in pthread_start_thread_event (arg=0x4094bbe0) at 
>>> manager.c:298
>>> (gdb)
>>>
>>> I tweaked it a few ways, but it always seems to crash in a delete 
>>> operator.  The activateAlarm code only reads the PDU without 
>>> changing it, so I dont suspect it.
>>>
>>> The biggest change I made was to move the new and delete for vbs 
>>> inside the while loop.  In that case, the crash happens in the new 
>>> operator when it's trying to set a new value into an existing Vbx:
>>>
>>> (gdb) where
>>> #0  chunk_alloc (ar_ptr=0x404c4620, nb=32) at malloc.c:2983
>>> #1  0x40410028 in __libc_malloc (bytes=24) at malloc.c:2811
>>> #2  0x4027a00d in __builtin_new (sz=24) from 
>>> /usr/lib/libstdc++-libc6.2-2.so.3
>>> #3  0x4036f2a3 in Vb::set_value (this=0x80d3a4c, ptr=0x80c3940 
>>> "descr") at vb.cpp:224
>>> #4  0x08057fdc in Agentpp::ttiTrapThread::buildAlarmVb 
>>> (this=0x404c4650, nmEv=@0x4094ba0c, vbs=0x80d3988, seqNum=1) at 
>>> ttiTrapThread.cpp:231
>>> #5  0x0805732d in Agentpp::ttiTrapThread::run (this=0x80d2df0) at 
>>> ttiTrapThread.cpp:139
>>> #6  0x402eb315 in Agentpp::TaskManager::run (this=0x80d30f0) at 
>>> threads.cpp:724
>>> #7  0x402e9f40 in Agentpp::thread_starter (t=0x80d3118) at 
>>> threads.cpp:472
>>> #8  0x40244b9c in pthread_start_thread (arg=0x4094bbe0) at 
>>> manager.c:274
>>> #9  0x40244c7f in pthread_start_thread_event (arg=0x4094bbe0) at 
>>> manager.c:298
>>> (gdb)
>>>
>>> Any ideas?  Thanks,
>>> Dave
>>>
>>>