Hi, I am implementing an snmp agent using using code skeletons originally generated using mib2c -c mib2c.iterate.conf
When implementing a table, I have 5 functions that are called by the netsnmp library: get_first_data_point get_next_data_point free_loop_context_at_end free_data_context And the handler function itself. In the get_first_data_point function I do the following 1) allocate an integer pointer which is used as an index to each row. This integer is freed at the end of each iteration in the function free_loop_context_at_end. 2) allocate a succession of linked list nodes for each row of the table. Each node stores information about that each row and contains a pointer to the next rows data which is set to NULL if it is the last row. In the get_next_data_point function move to the next linked list node and increment the my_loop_context (integer). If the next node is 0, i return NULL. In the free_loop_context_at_end function, i cast the ptr to an integer and free() it. In the free_loop_context_at_end function, i cast the ptr to my linked list node type and free it. Now, the problem is when I trace the order of callbacks and see what occurs, I see that memory (for my linked list nodes) that has been freed by free_data_context is subsequently used by get_next_data_point. ROUTE: Made route node at 0x134756736 ROUTE: Made route node at 0x134764784 ROUTE: Made route node at 0x134764816 ROUTE: Made routeTable # All the above occurs (3 nodes are malloc'd) in the get first function # The following shows what occurs in the get_next and free_data functions ROUTE: Moved from 0x134756736 to 0x134764784 ROUTE: Freeing data 0x134764784 # At this point the linked list node at 0x134764784 should not be accessed # However the next line shows the pointer is passed to the get_next function # to move to the subsequent node. ROUTE: Moved from 0x134764784 to 0x134764816 ROUTE: Freeing data 0x134764816 ROUTE: Moved from 0x134764816 to 0x0 ROUTE: Freeing int 0x134756768 ROUTE: Handler function called ROUTE: Freeing data 0x134756736 It seems that the free_data function is being called too early? I have noticed that for some tables, this doesn't cause problems, (i.e. no seg faults) however for other (larger node size) tables, I encounter segmentation faults as shown below: VIDEO: Made video proxy node at 0x134836944 VIDEO: Made video proxy node at 0x134837512 VIDEO: Made video proxy node at 0x134838080 VIDEO: Made video proxy node at 0x134838648 VIDEO: Made video proxy node at 0x134839216 VIDEO: Made video proxy node at 0x134839784 VIDEO: Made videoProxyTable VIDEO: moved from 0x134836944 to 0x134837512 VIDEO: Freeing data 0x134837512 VIDEO: moved from 0x134837512 to 0x568 VIDEO: Freeing data 0x568 Segmentation fault This shows that the next pointer in the node at address 0x134837512 has been modified from 0x134838080 to 0x568. This is likely to have occurred as the memory that was at 0x134837512 was freed the step before and thus the memory may be re-used. Note that this error seems only to cause seg faults when each linked list node is large, regardless of the number of nodes in the list (video proxy node is larger than a route node) Have I understood the situation correctly, and am I using the library in the correct manner? Regards, Mark. ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ Net-snmp-coders mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
