Corrections in BOLD below I referenced an incorrect routine..... sorry.
Need Help <[EMAIL PROTECTED]> wrote: 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 by
"snmp_select_info()" routine 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
the "snmp_select_info()" routine changes the blocking request might not even be
a problem at all since the addresses in the "Session" linked list are still
valid after the "snmp_select_info()" routine is called. 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.
---------------------------------
Shape Yahoo! in your own image. Join our Network Research Panel today!
---------------------------------
Luggage? GPS? Comic books?
Check out fitting gifts for grads at Yahoo! Search.-------------------------------------------------------------------------
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
