Bug 151040 - snmpd crashes on 'reading premib configuration tokens' on some pre-p4 systems
snmpd crashes on 'reading premib configuration tokens' on some pre-p4 systems
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: net-snmp (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Radek Vokal
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-14 06:19 EST by Vincent Schonau
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-01 08:46:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Partial output from starting 'snmpd -D -f' on the SMP system (1.99 KB, text/plain)
2005-03-14 06:20 EST, Vincent Schonau
no flags Details
A partial 'strace' of snmpd -f (with no other options) on the SMP system (4.47 KB, text/plain)
2005-03-14 06:21 EST, Vincent Schonau
no flags Details
partial output from running 'snmpd -D -f' from the UP system (1.82 KB, text/plain)
2005-03-14 06:21 EST, Vincent Schonau
no flags Details
Partial strace from starting 'snmpd -f' on the UP system (6.37 KB, text/plain)
2005-03-14 06:22 EST, Vincent Schonau
no flags Details

  None (edit)
Description Vincent Schonau 2005-03-14 06:19:20 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/125.5.6 (KHTML, like Gecko) Safari/125.12

Description of problem:
On two out of 4 FC3 systems I own, snmpd segfaults during it's startup.

On two other systems, this problem does not occur. The affected systems are a PII/266 UP, and a dual PIII/550 SMP system (the non-affected systems are both P4).

I've put some strace and snmpd -D output from the affected systems in the attachments section. I can provide full straces or coredumps if necessary.

Version-Release number of selected component (if applicable):
net-snmp-5.1.2-11

How reproducible:
Always

Steps to Reproduce:
'service snmpd start'
or any other snmpd start sequence.    

Actual Results:  segmentation fault.

Expected Results:  normal startup of snmpd (or an appropriate error message).

Additional info:
Comment 1 Vincent Schonau 2005-03-14 06:20:30 EST
Created attachment 111971 [details]
Partial output from starting 'snmpd -D -f' on the SMP system
Comment 2 Vincent Schonau 2005-03-14 06:21:04 EST
Created attachment 111972 [details]
A partial 'strace' of snmpd -f (with no other options) on the SMP system
Comment 3 Vincent Schonau 2005-03-14 06:21:46 EST
Created attachment 111973 [details]
partial output from running 'snmpd -D -f' from the UP system
Comment 4 Vincent Schonau 2005-03-14 06:22:18 EST
Created attachment 111974 [details]
Partial strace from starting 'snmpd -f' on the UP system
Comment 5 Radek Vokal 2005-03-14 06:36:38 EST
Can you please try latest net-snmp-5.2.1 from rawhide?
Comment 6 Vincent Schonau 2005-03-14 09:51:42 EST
Installing net-snmp-5.2.1 through yum from 'development' pulls in a
larger number of upgrades of other packages than I'd be willing to
install (almost everything :). So I took the 5.2.1 src.rpm and
--rebuilt that on one of the affected systems. 

The results are below; snmpd -D log and snmpd partial strace
(separated by ---cut). It appears to be segfaulting in a different
place, now.

---cut 
trace: _ioctl_get(): if-mib/data_access/interface_ioctl.c, 42:
verbose:access:interface:ioctl: ioctl 35111 for sit0
trace: netsnmp_access_interface_ioctl_flags_get():
if-mib/data_access/interface_ioctl.c, 229:
access:interface:ioctl: flags_get
trace: _ioctl_get(): if-mib/data_access/interface_ioctl.c, 42:
verbose:access:interface:ioctl: ioctl 35091 for sit0
trace: netsnmp_access_interface_ioctl_mtu_get():
if-mib/data_access/interface_ioctl.c, 349:
access:interface:ioctl: mtu_get
trace: _ioctl_get(): if-mib/data_access/interface_ioctl.c, 42:
verbose:access:interface:ioctl: ioctl 35105 for sit0
trace: netsnmp_access_interface_container_free():
if-mib/data_access/interface_common.c, 167:
access:interface:container: free
trace: netsnmp_access_interface_entry_free():
if-mib/data_access/interface_common.c, 314:
access:interface:entry: free
trace: netsnmp_access_interface_entry_free():
if-mib/data_access/interface_common.c, 314:
access:interface:entry: free
trace: netsnmp_access_interface_entry_free():
if-mib/data_access/interface_common.c, 314:
access:interface:entry: free
trace: should_init(): mib_modules.c, 127:
mib_init: initializing: lmSensors

---cut 
read(10, "ISA main adapter\n", 4096)    = 17
close(10)                               = 0
munmap(0xb7ffe000, 4096)                = 0
getdents64(9, /* 0 entries */, 4096)    = 0
close(9)                                = 0
open("/sys/class/i2c-adapter",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 9
fstat64(9, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
fcntl64(9, F_SETFD, FD_CLOEXEC)         = 0
getdents64(9, /* 4 entries */, 4096)    = 112
open("/sys/class/i2c-adapter/i2c-1/device/name", O_RDONLY) = 10
fstat64(10, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7ffe000
read(10, "SMBus PIIX4 adapter at e800\n", 4096) = 28
close(10)                               = 0
munmap(0xb7ffe000, 4096)                = 0
open("/sys/class/i2c-adapter/i2c-0/device/name", O_RDONLY) = 10
fstat64(10, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7ffe000
read(10, "ISA main adapter\n", 4096)    = 17
close(10)                               = 0
munmap(0xb7ffe000, 4096)                = 0
getdents64(9, /* 0 entries */, 4096)    = 0
close(9)                                = 0
ioctl(8, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbffd6c48) = -1 ENOTTY
(Inappropriate ioctl for device)
fstat64(8, {st_mode=S_IFREG|0644, st_size=64783, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7ffe000
read(8, "# Sensors configuration file use"..., 8192) = 8192
read(8, " SMBus adapter\"\n#\n# If we refer "..., 8192) = 8192
read(8, "nsistor;\n# 3435 = thermistor wit"..., 8192) = 8192
read(8, " temperatures settled like that:"..., 8192) = 8192
read(8, "he absolute values\n# of the read"..., 8192) = 8192
read(8, "2 \"-5V\"\n#   set AIN1_min -12 * 0"..., 8192) = 8192
read(8, "Fan2/CPU0\"\n    label  fan3      "..., 8192) = 8192
read(8, "         253 - (210 / (1 + (1 / "..., 8192) = 7439
read(8, "", 4096)                       = 0
read(8, "", 8192)                       = 0
ioctl(8, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbffd6c58) = -1 ENOTTY
(Inappropriate ioctl for device)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
Comment 7 Vincent Schonau 2005-03-21 07:46:40 EST
(In reply to comment #5)
> Can you please try latest net-snmp-5.2.1 from rawhide?

When I rebuild this src.rpm on one of the problem systems, the problem persists.
When I rebuild it on one of the systems that isn't affected, and then install
the resulting binary rpms on the affected systems, snmpd does not crash.

Comment 8 Radek Vokal 2005-03-21 07:54:18 EST
That seems to lead somewhere. Can you compare the lmsensors-devel versions that
you have on both systems? 
Comment 9 Vincent Schonau 2005-03-21 08:06:44 EST
(In reply to comment #8)
> That seems to lead somewhere. Can you compare the lmsensors-devel versions that
> you have on both systems? 

Both are 2.8.8-5, taken from the rawhide source RPM and rebuilt on each of the
hosts. 

so the affected host currently has 

net-snmp-5.2.1-5 built on _non_ affected host and lm-sensors 2.8.8-5 built on
_affected_ host.

non-affected host has
net-snmp-5.2.1-5 built on _non_ affected host and lm-sensors 2.8.8-5 built on
_non_ affected host (itself).

Does that answer your question?
Comment 10 Radek Vokal 2005-03-21 08:39:17 EST
It answers my question, but doesn't shed much light on the problem :) There has
to be some build difference between an _affected_ system on the other one. I
assume that /etc/snmpd.conf files are same. It seems like the bug is caused by
some lm_sensors call (does `sensors` show correct output on both machines?) 

I saw few crashes with net-snmp-5.1.2 due to limited number of sensors (the
maximum was only 32). In net-snmp-5.2.1 the sensors maximum is 128 so I suppose
there's another problem and thanks for testing it with new net-snmp as well. 
Comment 11 Radek Vokal 2005-05-12 04:41:39 EDT
I've pushed out new net-snmp update for FC3. Is this bug still present with the
latest version? 

Note You need to log in before you can comment on or make changes to this bug.