WH>Well, threading does cause concerns since the Net-SNMP agent is not
WH>thread-safe at all. But if it's run in a single thread itself, I think
WH>it should work assuming you take careful control of pointers going into
WH>and out of the Net-SNMP thread and never allowing them to be used in two
WH>threads (IE, always copy the data).
The main thread never touches net-snmp from the moment that the service
thread is started. The interaction model is to have the application provide
only get*() and set*() access methods in the main code, called by net-snmp,
with no assumptions on the part of the main code about what is happening
in net-snmp.
WH>Are you using snmp_set_var_value() in the _next_data_point() function?
WH>or copying them in in some other way? Is the data copied (like
WH>snmp_set_var_value() does)? Is the pointer just inserted?
I was able this morning to make net-snmp source visible under ddd, and
I have been inserting printf()'s in net-snmp to get an idea what it is
doing. The crash occurs after four calls to the following
_next_data_point():
netsnmp_variable_list *
dmmaiohDeviceTable_get_next_data_point(void **my_loop_context,
void **my_data_context,
netsnmp_variable_list *
put_index_data,
netsnmp_iterator_info *mydata)
{
struct dmmaiohDeviceTable_entry *entry =
(struct dmmaiohDeviceTable_entry *) *my_loop_context;
netsnmp_variable_list *idx = put_index_data;
if (entry) {
printf("dmmaiohDeviceTable_get_next_data_point()1: 0x%x 0x%x\n", idx,
idx->name);
printf("dmmaiohDeviceTable_get_next_data_point()2: 0x%x 0x%x\n", entry,
entry->next);
fflush(stdout);
snmp_set_var_value(idx, (u_char *) & entry->deviceSerNo,
sizeof(entry->deviceSerNo));
idx = idx->next_variable;
*my_data_context = (void *) entry;
*my_loop_context = (void *) entry->next;
} else {
return NULL;
}
}
I'm trying not to take any liberties with functional structure, so I think
I am duplicating the structure in the examples without assumptions about the
actual structure of the data manipulated. I am calling
snmp_set_var_value(),
I think, just as in the examples. The printf()'s and fflush() have been
hacked into the autogenerated code, after autogeneration.
My linked list looks like this:
/*
* Typical data structure for a row entry
*/
struct dmmaiohDeviceTable_entry {
/*
* Index values
*/
long deviceSerNo;
// Pointer to class instance associated with this row
void *object;
struct dmmaiohDeviceTable_entry *next;
};
struct dmmaiohDeviceTable_entry *dmmaiohDeviceTable_head = NULL;
The pointer "object" points to the class where the get* and set* methods
reside. These are called and return values without problem.
Each time _next_data_point() is called, I see the same my_loop_context, but
different idx and idx->name. Idx and idx->name look like valid addresses,
so I assume there is no malfunction there.
The first three times build_oid_noalloc() and build_oid_segment() are
called,
var and var->name contain valid-looking addresses, but, the last time,
var contains an address of the form "0x...000", possibly in the .data or
.bss
segments of the application, and var->name always contains 0x10101, which is
certainly not an address. It is the dereference of this value which causes
the segmentation fault. I haven't found just what code is generating the
bad address, but, with the ability to compile net-snmp, I should know pretty
soon.
WH>You might try using valgrind for doing debugging. It's great for
WH>detecting memory related errors (once you can get the hang of using it).
That sounds good, but, at the moment, I'm hoping not to require it.
Thanks for the help,
Leo Bredehoft
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
