http://bugzilla.novell.com/show_bug.cgi?id=520623 User mkuzbinski@alcatel-lucent.com added comment http://bugzilla.novell.com/show_bug.cgi?id=520623#c1 Summary: net-snmp snmpd 5.3.0.1 core during high traffic Classification: openSUSE Product: openSUSE 10.3 Version: Final Platform: x86-64 OS/Version: SuSE Linux 10.0 Status: NEW Severity: Normal Priority: P5 - None Component: Other AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: mkuzbinski@alcatel-lucent.com QAContact: qa@suse.de Found By: --- User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 1) net-snmp-5.3.0.1-25.31 2) Linux host01 2.6.16.60-0.21-smp #1 SMP Tue May 6 12:41:02 UTC 2008 x86_64 x86_64 x86_64 GNU/Linux 3) LSB Version: core-2.0-noarch:core-3.0-noarch:core-2.0-x86_64:core-3.0-x86_64:desktop-3.1-amd64:desktop-3.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch Distributor ID: SUSE LINUX Description: SUSE Linux Enterprise Server 10 (x86_64) Release: 10 Codename: n/a Description: While running stability run (2500 UDP packages send/received per second) there was core dump observed from snmpd process. The stack displayed by gdb seems to be not correct: (gdb) where #0 0x00002abaf74a9111 in memcpy () from /lib64/libc.so.6 #1 0x0000000000000000 in ?? () however based on %rsp register I managed to reproduce the stack calls which (not sure) looks like this: memcpy (0, 1, 344) ??? netsnmp_access_systemstats_entry_update_stats netsnmp_access_systemstats_entry_update This leads to systemstats_common.c - function netsnmp_access_systemstats_entry_update_stats() which has an interesting part of code: 00337 /* 00338 * if we've decided we no longer need to check wraps, free old stats 00339 */ 00340 if (0 == need_wrap_check) { 00341 SNMP_FREE(prev_vals->old_stats); 00342 } 00343 00344 /* 00345 * update old stats from new stats. 00346 * careful - old_stats is a pointer to stats... 00347 */ 00348 memcpy(prev_vals->old_stats, &new_vals->stats, sizeof(new_vals->stats)); 00349 00350 return 0; when need_wrap_check is 0, in the line 348 we would have an attempt to copy to null pointer. I'm not sure when "need_wrap_check" is set, I hoped to reproduce the core and looked at InReveices in snmpwalk command: snmpwalk -v2c -c public localhost 1.3.6.1.2.1.4.31.1 ipSystemStatsInReceives.ipv4 = Counter32: 4294961229 ipSystemStatsInReceives.ipv6 = Counter32: 108 ipSystemStatsHCInReceives.ipv4 = Counter64: 8589928525 ipSystemStatsHCInReceives.ipv6 = Counter64: 108 but ipSystemStatsInReceives.ipv4 counter wrapped and core did not occured. I'm wondering if this part of code might be the source of snmpd cores. Reproducible: Sometimes Steps to Reproduce: 1. Run UDP traffic and wait hours, days ... Opened ticked also under https://sourceforge.net with following response: Message: Bug reports against the net-snmp SLES10 package need to be filed with Novell bugzilla, not here, unless you can reproduce the problem with The Net-SNMP Project's current SVN version (5.3.x branch or trunk). -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.