varbind management/construction problem

[Frank Fock]

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