Description of problem: "snmpwalk -v2c -c public -m ALL 127.0.0.1 .1.3" results in an segfault of snmpd /var/log/messages: snmpd[7853]: segfault at 0000557555989a9c rip 00002aaaab6cdd76 rsp 00007fff20e91cf0 error 6 Version-Release number of selected component (if applicable): net-snmp x86_64 1:5.3.1-12.fc6 net-snmp-utils x86_64 1:5.3.1-12.fc6 How reproducible: "snmpwalk -v2c -c public -m ALL 127.0.0.1 .1.3" on a intel woodcrest (64bit) Steps to Reproduce: 1. start snmpd with pubic community for localhost 2. run snmpwalk -v2c -c public -m ALL 127.0.0.1 .1.3 3. check /var/log/messages or service snmpd restart Actual results: /var/log/messages: snmpd[7853]: segfault at 0000557555989a9c rip 00002aaaab6cdd76 rsp 00007fff20e91cf0 error 6 Expected results: no segfault Additional info: I started snmpd with -d -f The result is attached (ip-adresses changed)
Created attachment 147748 [details] result of snmpd -d -f
I tested this on three machines, which are all of the type (Dell)PowerEdge 1950. http://www.dell.com/content/products/productdetails.aspx/pedge_1950?c=us&cs=555&l=en&s=biz&~section=specs#tabtop with Intel(R) Xeon(R) CPU 5160 3.00GHz. All three behaved exactly the same. I have installed a plain fedora 6 without extra software. uname -a on two of these machines (one had a reboot -> updated kernel in use) Linux woodcrest01 2.6.18-1.2869.fc6 #1 SMP Wed Dec 20 14:51:34 EST 2006 x86_64 x86_64 x86_64 GNU/Linux Linux woodcrest04 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:39:22 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux
Created attachment 147780 [details] coredump This is the core-dump I forgot to attach. It was created with "ulimit -c unlimited" and "snmpd -d -f" (I changed the included ip to 111.222.333 and the hostname - I hope there is no checksum included)
Do you have debuginfo package installed because I don't see any symbols in the core file. Also do you know which exact MIB is causing the segfault? I haven't manage to reproduce it here, works smoothly on my x86_64 box.
Created attachment 149129 [details] output of smnpwalk until it segfaults
Sorry, that it took so long for me to answer... Here I am back again :) I have searched for "debuginfo" package on fedora core 6, but cannot find any package like that. Please tell me what exactly you mean with "debuginfo" and where I can find them. The MIB which causes the segfault is probably the last entry printed to the screen when doing snmpwalk -v2c -c public -m ALL 127.0.0.1 .1.3. I attached the output of snmpwalk in comment #5.
Created attachment 149267 [details] core dump with net-snmp-debuginfo Backtrace: #0 0x00002aaaab6cdd76 in netsnmp_hex_to_binary () from /usr/lib64/libnetsnmp.so.10 #1 0x00002aaaaad6ace8 in netsnmp_arch_tcpconn_container_load () from /usr/lib64/libnetsnmpmibs.so.10 #2 0x00002aaaaad6a5e7 in netsnmp_access_tcpconn_container_load () from /usr/lib64/libnetsnmpmibs.so.10 #3 0x00002aaaaad6e785 in tcpConnectionTable_container_load () from /usr/lib64/libnetsnmpmibs.so.10 #4 0x00002aaaab25b3d4 in netsnmp_cache_timer_start () from /usr/lib64/libnetsnmphelpers.so.10 #5 0x00002aaaab25bb20 in netsnmp_cache_helper_handler () from /usr/lib64/libnetsnmphelpers.so.10 #6 0x00002aaaab0277ce in netsnmp_call_handler () from /usr/lib64/libnetsnmpagent.so.10 #7 0x00002aaaab26ae64 in table_helper_handler () from /usr/lib64/libnetsnmphelpers.so.10 #8 0x00002aaaab0277ce in netsnmp_call_handler () from /usr/lib64/libnetsnmpagent.so.10 #9 0x00002aaaab01ad5f in handle_var_requests () from /usr/lib64/libnetsnmpagent.so.10 #10 0x00002aaaab01bde0 in handle_getnext_loop () from /usr/lib64/libnetsnmpagent.so.10 #11 0x00002aaaab01d228 in netsnmp_handle_request () from /usr/lib64/libnetsnmpagent.so.10 #12 0x00002aaaab01de07 in handle_snmp_packet () from /usr/lib64/libnetsnmpagent.so.10 #13 0x00002aaaab6b98ca in snmpv3_parse () from /usr/lib64/libnetsnmp.so.10 #14 0x00002aaaab6ba8b1 in _sess_read () from /usr/lib64/libnetsnmp.so.10 #15 0x00002aaaab6bb319 in snmp_sess_read () from /usr/lib64/libnetsnmp.so.10 #16 0x00002aaaab6bb363 in snmp_read () from /usr/lib64/libnetsnmp.so.10 #17 0x0000555555559236 in main (argc=<value optimized out>, argv=<value optimized out>) at snmpd.c:1152
I installed the packet net-snmp-debuginfo and attached the core-dump (hopefully with symbols now) of "snmpd -d -f" after executing "snmpwalk -v2c -c public -m ALL 127.0.0.1 .1.3" Backtrace: gdb /usr/lib/debug//usr/sbin/snmpd.debug core.30170 >bt #0 0x00002aaaab6cdd76 in netsnmp_hex_to_binary () from /usr/lib64/libnetsnmp.so.10 #1 0x00002aaaaad6ace8 in netsnmp_arch_tcpconn_container_load () from /usr/lib64/libnetsnmpmibs.so.10 #2 0x00002aaaaad6a5e7 in netsnmp_access_tcpconn_container_load () from /usr/lib64/libnetsnmpmibs.so.10 #3 0x00002aaaaad6e785 in tcpConnectionTable_container_load () from /usr/lib64/libnetsnmpmibs.so.10 #4 0x00002aaaab25b3d4 in netsnmp_cache_timer_start () from /usr/lib64/libnetsnmphelpers.so.10 #5 0x00002aaaab25bb20 in netsnmp_cache_helper_handler () from /usr/lib64/libnetsnmphelpers.so.10 #6 0x00002aaaab0277ce in netsnmp_call_handler () from /usr/lib64/libnetsnmpagent.so.10 #7 0x00002aaaab26ae64 in table_helper_handler () from /usr/lib64/libnetsnmphelpers.so.10 #8 0x00002aaaab0277ce in netsnmp_call_handler () from /usr/lib64/libnetsnmpagent.so.10 #9 0x00002aaaab01ad5f in handle_var_requests () from /usr/lib64/libnetsnmpagent.so.10 #10 0x00002aaaab01bde0 in handle_getnext_loop () from /usr/lib64/libnetsnmpagent.so.10 #11 0x00002aaaab01d228 in netsnmp_handle_request () from /usr/lib64/libnetsnmpagent.so.10 #12 0x00002aaaab01de07 in handle_snmp_packet () from /usr/lib64/libnetsnmpagent.so.10 #13 0x00002aaaab6b98ca in snmpv3_parse () from /usr/lib64/libnetsnmp.so.10 #14 0x00002aaaab6ba8b1 in _sess_read () from /usr/lib64/libnetsnmp.so.10 #15 0x00002aaaab6bb319 in snmp_sess_read () from /usr/lib64/libnetsnmp.so.10 #16 0x00002aaaab6bb363 in snmp_read () from /usr/lib64/libnetsnmp.so.10 #17 0x0000555555559236 in main (argc=<value optimized out>, argv=<value optimized out>) at snmpd.c:1152
can you start snmpd with -Dverbose:access:tcpconn and post the last few lines of debug output?
Created attachment 149437 [details] The last lines of snmpwalk after "snmpd -Dverbose:access:tcpconn" snmpd -Dverbose:access:tcpconn > No log handling enabled - turning on stderr logging > registered debug token verbose:access:tcpconn, 1 > NET-SNMP version 5.3.1 The last lines of snmpwalk are attached
I found the following in /var/log/messages: snmpd[1768]: looks like a 64bit wrap, but prev!=new perhaps that helps....
I can reproduce this segfault everytime with a Xen guest running RHEL5 and net-snmp-5.3.1-14.el5.
I switched to the new kernel and did a "yum update" (fedora core 6) on all machines, but snmpd still segfaults :(
I am sorry we failed to fix the bug. FC6 is not supported anymore. Could you please try to reproduce the bug on Fedora 7 or 8 and attach your snmpd.conf and snmpd output (in syslog, i.e. /var/log/messages)?
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and will not be fixed by Fedora. Therefore we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen thus bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.