On 31 July 2012 08:30, Naama Bar Menachem
<naama.barmenac...@novelsat.com> wrote:
> There is no double-free problem. The free is only called once and
> crashes on the first time.
Well *something* is wrong with it!
The usual causes of problems with releasing memory are:
- freeing a NULL pointer
- freeing a pointer twice
- freeing a pointer that wasn't allocated dynamically
You could try compiling with one of the memory debugging tools
(dmalloc, or libefence) to try and analyse where things are
going wrong.
> However, there is something I don't understand. As I said the data is
> not stored locally on the agent, but on kernel. When the device is
> loaded, there is always 5 rows in the table. Where those 5 rows are
> allocated and stored in the local agent table?
The agent typically keeps a local cached version of the underlying
table being monitored. This could be a complete copy of all of the
data from that table - or else a "skeleton" table, containing a dummy
entry for each row of the table (with the actual data being looked up
from the kernel in the handler).
However this is done, it's usually set up in the 'createEntry' routine.
Looking at your code, the entry that is set up in this routine is never
actually used. You allocate a memory structure, but the block of
code
'XXX - insert entry into local data structure'
is empty.
So the per-row data structure that you create here is simply dropped.
The entry you work with elsewhere is set up within the
nsCommonConfigDataForwardPolicyRouteTable_get_entry()
routine, and seems to refer to a global buffer
(which doesn't need freeing)
Hence the cause of the crash is case 3 above.
> In addition, I added a new row, and immediately destroyed it. I printed
> the address the entry is pointing to, and it seems that in
> "create_entry" the allocated entry is pointing to "0x1201f6160", while
> on "remove_entry" it is pointing to "0x555aa6dc98".
See above.
If you are using your own mechanism for retrieving data from the
underlying kernel - then you need to extend this to apply to updating
values and creating/deleting rows as well. You probably need to
replace the *whole* of the createEntry & deleteEntry routines with
versions that work with your kernel table.
Similarly for the SET processing of the column values.
You apply the new values within the Action pass, but don't
seem to be reversing this in the Undo pass, if some part
of the SET fails.
Dave
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
