varbind management/construction problem

[Dave Mason]

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
>
>