I figured out the core dump is caused by an invalid pointer being used.
My subagent.c code file calls routine "agent_check_and_process()" which calls
the "snmp_timeout()" routine (provided below).
snmp_timeout(void)
{
struct session_list *slp;
snmp_res_lock(MT_LIBRARY_ID, MT_LIB_SESSION);
for (slp = Sessions; slp; slp = slp->next) {
snmp_sess_timeout((void *) slp);
}
snmp_res_unlock(MT_LIBRARY_ID, MT_LIB_SESSION);
}
The core dump is caused by an invalid pointer being passed into the
"snmp_sess_timeout()" routine. As a result, a core dump occurs inside the
"snmp_sess_timeout()" routine when this pointer is first accessed via the
following line of code:
sp = slp->session;
The "snmp_timeout()" routine is getting the invalid pointer from the "Sessions"
linked list variable it seems. Can someone please explain what "Sessions" is
and perhaps why this might be holding an invalid pointer.
When the core dump occurs (ie: when loading our main application and the
subagent application together), then the address that comes from "Sessions" is
0x40000
When the subagent is loaded by itself (ie: everything works), then a good
address of 0x10332d30 is being provided.
There is a big difference in these address ranges, so hopefully someone can
shed some light on what might be going on here?
Need Help <[EMAIL PROTECTED]> wrote: In the subagent file (ie:
"snmpSubagent_ocStbHostMib.c"), the main routine is called to initialize the
subagent and start it running. Actually, I changed the name from "main()" to
"snmp_subagent_main()". Anyway, inside of this function, there is call to
"agent_check_and_process()", which obviously calls the "snmp_timeout()" routine
which in turn calls the "snmp_sess_timeout()" routine.
Here is code trace in the coredump:
#0 0x2cc86684 in snmp_sess_timeout ()
#1 0x2cc85bd8 in snmp_timeout ()
#2 0x2cb1ebb0 in agent_check_and_process ()
#3 0x2c8c6fac in snmp_subagent_main
Will someone please explain to me what the "agent_check_and_process()",
"snmp_timeout()" and "snmp_sess_timeout()" routines are doing? I looked into
the code but I really have no idea. Hopefully knowing more about the routines
above will help me figure out what is going on.
Since the subagent works fine when the subagent is started by itself, then
something obviously is conflicting when I request our "main application" to
start with the subagent. I am assuming since our "main application" is
starting up, then this is somehow starving the subagent for time thus making it
timeout.
.... or perhaps calling the "snmp_timeout()" and "snmp_sess_timeout()" routines
are normal? Any help/ideas would be appreciated.
Need Help <[EMAIL PROTECTED]> wrote: I was successful in getting the subagent
to start upon booting up our hardware box. Once the box comes up, I can then
telnet to it and start the snmpd master agent successfully and then I could
see the subagent attach itself to the master agent eventually. I then can run
SNMP requests and everything works great.
** Note: The master agent is started manually once the box comes up for testing
only (until we integrate that into our load build process).
Normally our hardware box would start up our "main application" upon reboot
first, however, for testing purposes I was told to simply start the subagent
SNMP application only. Anyway, since I had the subagent and master agent
stuff working perfectly, I decided to put back in the logic to start our "main
application" first and then follow this with starting up the subagent
application.
When I reboot the box, I can see the "main application" is requested to start
and then I see the subagent is requested to start. At this early booting
stage, I can even telnet into our box and start up the master agent and perform
a subagent-specific query to verify it works fine.
Then after about 20 to 30 seconds into our boot process, I get a segmentation
core dump. It seems something to do with the subagent is timing out perhaps
... dont know. Does anyone have any ideas on what could be causing this?
Again, if I reboot the box and start only the subagent application OR only the
"main application" then each application works fine, however, when they both
try to start up during reboot processing, then I always get a coredump.
The (gdb) trace is provided below:
Program terminated with signal 11, Segmentation fault.
#0 0x2cc86684 in snmp_sess_timeout ()
from /opt/B173/1.97/usr/lib/debug/libnetsnmp.so.15
(gdb) #0 0x2cc86684 in snmp_sess_timeout ()
from /opt/B173/1.97/usr/lib/debug/libnetsnmp.so.15
#1 0x2cc85bd8 in snmp_timeout ()
from /opt/B173/1.97/usr/lib/debug/libnetsnmp.so.15
#2 0x2cb1ebb0 in agent_check_and_process ()
from /opt/B173/1.97/usr/lib/debug/libnetsnmpagent.so.15
#3 0x2c8c6fac in snmp_subagent_main (argc=1, argv=0x10000)
at
/export/home/rosent1/vegasCC/1.97/reuse/lib/ice/services/snmp/subagent/netsnmp/ocstbhostmib/agentX/src/snmpSubagent_ocStbHostMib.c:113
agentx_subagent = 1
background = 0
syslog = 0
#4 0x2bc992f8 in Applications_Init (argv=0x0)
at
/export/home/marlin/builds/B173/1.97/reuse/lib/ice/adaptation/mot/init/src/DCT_Init.cpp:304
lineCounter = 2
rc = 0
deviceName = <incomplete type>
iniFileName = <incomplete type>
appSymbols = (PLD_SymbolTable *) 0x10328be8
sym = 0x2c8c6d70
pModuleName = (PCT_Char *) 0x1030c6f0 "/libsnmp_subagent.so"
pModuleEntryName = (PCT_Char *) 0x1030c705 "snmp_subagent_main"
pData = (PCT_Char *) 0x1030c6cc "//libdct_tvguide.so"
bufferSize = 76
dynamicMain = 0x30000
#5 0x2bc988b4 in adaptation_layer_init (argv=0x7fff7e24)
at
/export/home/marlin/builds/B173/1.97/reuse/lib/ice/adaptation/mot/init/src/DCT_Init.cpp:137
rc = 0
rc1 = 0
#6 0x0040096c in main (argc=196608, argv=0x30000)
at
/export/home/marlin/builds/B173/1.97/reuse/lib/ice/adaptation/mot/init/test/src/dct_inittest.cpp:40
---------------------------------
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail,
news, photos & more.
-------------------------------------------------------------------------
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
---------------------------------
Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV.
-------------------------------------------------------------------------
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
---------------------------------
Luggage? GPS? Comic books?
Check out fitting gifts for grads at Yahoo! Search.
---------------------------------
Need a vacation? Get great deals to amazing places on Yahoo! Travel. -------------------------------------------------------------------------
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
