Thanks for responding ...
Ok, I guess I did not explain this clear enough then. I did read the code
comment (you referenced) before and realize the "select()" routine is not
blocking because it is using a "modified timeout returned by
snmp_select_info()". However, I do not understand why "there is an alarm due
sooner than LONG_MAX seconds from now" which is causing a "modified timeout" to
be returned by "snmp_select_info()".
I only included the values of "block" and "fakeblock" so it would be clear as
to which path through the "agent_check_and_process()" code routine was being
taken. I understand the execution goes through the "else if (block != 0 &&
fakeblock == 0)" part of the code, but I really have no idea whether this is a
problem or not. It seems I am requesting "select()" to block since the
"agent_check_and_process()" routine is passing in a "1" as a parameter, so I am
not sure if it is normal behavior that this request is changed due to an alarm
occurring.
My main problem is that after the call to "select()" occurs, then the "Session"
linked list has an invalid address in it. This causes the coredump. Knowing
that "select()" does not block might not even be a problem at all since the
addresses in the "Session" linked list are still valid after this occurs. Also
since it looks like the NetSNMP "snmp_api.c" module is the only module which
defines and uses the "Sessions" linked list, I am not sure how anything else is
manipulating it. The snmpd master agent is not even started yet, so this can
not be doing anything with it. The only thing related to NetSNMP which is
started is my "one" subagent.
Questions:
1) I know why the "select" routine is not blocking (based on the values of
"block" and "fakeblock" but I do not know if this is normal. Should I be
looking into why "there is an alarm due sooner than LONG_MAX seconds from now"
being reported by the "snmp_select_info" routine? I do not know if this is
normal behavior or not.
2) Any ideas why my "Sessions" linked list is being corrupted when only my
"one" subagent is started?
Note: For testing purposes, if I bypass calling the "select()" routine
altogether and set "count=0", then the addresses within the "Sessions" linked
list remain as the same and I do not coredump.
[EMAIL PROTECTED] wrote: On Wed, August 1, 2007 11:07 pm, Need Help wrote:
Read this comment in the code you included, and note the conditional
expression.
> } else if (block != 0 && fakeblock == 0) {
> /*
> * The caller asked for blocking, but there is an alarm due
> sooner than
> * LONG_MAX seconds from now, so use the modified timeout
> returned by
> * snmp_select_info as the timeout for select().
> */
Now note the values you reported for these variables:
> After the call to the "snmp_select_info()" routine completes, the
> following variable values are displayed:
>
> "block" is not 0
> "fakeblock" is 0
And now hopefully you can answer your own question:
> Since I am not really performing any SNMP requests, I am not sure why
> the "select()" routine is not blocking (ie: waiting for a packet) for me.
Regarding select...
> I really do
> not understand what this has to do with the "Sessions" linked list either.
select has nothing to do with any net-snmp data structures.
> Is this a NetSNMP bug which results in the "Sessions" linked list being
> corrupted somehow?
select is a system call, so it will not be modifying any net-snmp data
structures unless maybe you've passed it a bad pointer. Are there other
threads running that may be modifying these data structures?
> I do not understand what the "select()" routine really does (I can not
> find it anywhere).
select is a POSIX-standard system call. Try man select. Or google "unix
select" or something along those lines.
Pete
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>
http://get.splunk.com/_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
---------------------------------
Choose the right car based on your needs. Check out Yahoo! Autos new Car
Finder tool.
---------------------------------
Choose the right car based on your needs. Check out Yahoo! Autos new Car
Finder tool.-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
