When executing /usr/local/sbin/snmpd -f -a -p /var/run/snmpd.pid -c /usr/local/share/snmp/snmpd.conf the daemo n immediately stops with a segmentation fault. I have compiled with WITH_DEBUG=YES, and run the deamon under the gdb debugger: [begin cut-and-paste] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc64-marcel-freebsd"... (gdb) run -f -a -p /var/run/snmpd.pid -c /usr/local/share/snmp/snmpd.conf Starting program: /usr/local/sbin/snmpd -f -a -p /var/run/snmpd.pid -c /usr/local/share/snmp/snmpd.conf Program received signal SIGSEGV, Segmentation fault. 0x0000000040408320 in mteObjects_createEntry (owner=0x40425fb0 "_snmpd", oname=0x40425fb8 "_triggerFire", index=2, flags=20) at disman/event/mteObjects.c:164 164 row->oid_index.oids[row->oid_index.len]++; (gdb) bt #0 0x0000000040408320 in mteObjects_createEntry (owner=0x40425fb0 "_snmpd", oname=0x40425fb8 "_triggerFire", index=2, flags=20) at disman/event/mteObjects.c:164 #1 0x00000000404084a0 in mteObjects_addOID (owner=0x40425fb0 "_snmpd", oname=0x40425fb8 "_triggerFire", index=2, oid_name_buf=0x40425fe0 ".1.3.6.1.2.1.88.2.1.2", wild=0) at disman/event/mteObjects.c:207 #2 0x0000000040407d38 in _init_default_mteObject (oname=0x40425fb8 "_triggerFire", object=0x40425fe0 ".1.3.6.1.2.1.88.2.1.2", index=2, wcard=0) at disman/event/mteObjects.c:50 #3 0x0000000040407e28 in _init_default_mteObject_lists (majorID=0, minorID=0, serverargs=0x0, clientarg=0x0) at disman/event/mteObjects.c:67 #4 0x00000000409ad43c in snmp_call_callbacks (major=0, minor=0, caller_arg=0x0) at callback.c:326 #5 0x0000000040998a0c in read_configs () at read_config.c:860 #6 0x000000004096094c in init_snmp (type=0x1078c8 "snmpd") at snmp_api.c:839 #7 0x00000000001052c4 in main (argc=7, argv=0x7fdffffeb98) at snmpd.c:906 [end cut-and-paste] The snmpd.conf file is: [begin cut-and-paste] syslocation "somewhere" syscontact bit-bucket@thismonkey.com sysservices 76 rocommunity hidden rwcommunity hidden trap2sink mail-01 public [end cut-and-paste] Fix: Not known. How-To-Repeat: start snmpd, either by hand with "/usr/local/sbin/snmpd -f -a -p /var/run/snmpd.pid -c /usr/local/share/snmp/s nmpd.conf" or with "/usr/local/etc/rc.d/snmpd start"
This issue is still present on FreeBSD 7-RELEASE; I just ran into myself converting a Netra box from OpenSolaris to FreeBSD. I did some debugging and discovered a workaround, the faulting component is in the disman/events MIB, so simply adding "-I -mteObjects" to snmpd_flags in rc.conf allows snmpd to start up and function, although presumably without mteObjects functionality, whatever that is. The following patch also *appears* to rectifiy the problem without disabling mteObjects: --- table_tdata.c.orig 2008-03-24 12:28:45.062698182 -0400 +++ table_tdata.c 2008-03-24 12:21:04.111822058 -0400 @@ -464,6 +464,9 @@ if (!table) return NULL; + if (!searchfor) + return NULL; + index.oids = searchfor; index.len = searchfor_len; return CONTAINER_FIND( table->container, &index ); The actual error occurs in mteObjects.c when the code tries to dereference a null pointer. I'm somewhat perplexed as to why this bug appears to only manifest on FreeBSD (Same hardware running Solaris 10/11 with net-snmp compiled from source has no such issue) and only on sparc64. The problem arises because the netsnmp_tdata_row_get_byoid function is matching newly created netsnmpt_tdata_rows which have null oid_index.oids pointers to objects in the objects_table_data global, which in turn is causing a branch in the code to be taken, which attempts to increment oid_index.oids[row->oid_index.len] on the row that has just been matched; since this is NULL, the problem segfaults. I'm unsure if the problem is because rows are being matched when they shouldn't be, or if oid_index.oids is just not being initialized properly somewhere. I can't see any initialization code being run in the codepath leading up to here (the new row is malloc'd and zeroed out just 30 lines before netsnmp_tdata_row_get_byoid is called) so my naive solution was to change the netsnmp_tdata_row_get_byoid function to immediately exit if given a null OID to search for, which appears to work for me, but I'm not familiar enough with the codebase to tell if that's the right thing to do in the long run. This appears to be an upstream issue that just got shaken out by the combination of architecture and compiler on sparc64, so I'm submitting it as a bug there as well, as it doesn't seem to exist in their bug tracker yet. Patrick Donnelly Enterprise Network Engineer Ocean Computer Group 90 Matawan Rd Suite 105 Matawan New Jersey, 07747 Office 732-493-1900 x245 phd@oceancomputer.com
Responsible Changed From-To: freebsd-sparc64->kuriyama Assign to maintainer.
Responsible Changed From-To: kuriyama->pgollucci Pass to new maintainer.
Responsible Changed From-To: pgollucci->freebsd-ports-bugs back to pool
Responsible Changed From-To: freebsd-ports-bugs->sylvio New maintainer is sylvio
Hi, This problem still continue? --=20 Regards, Sylvio Cesar=A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 || FreeBSD Committer || Team mul= timedia@FreeBSD.org sylvio@FreeBSD.org=A0 || http://people.freebsd.org/~sylvio || http://www.scjamorim.org || http://www.freebsd.org "Tenho posto o Senhor continuamente diante de mim; porque Ele est=E1 =E0 minha m=E3o direita, n=E3o vacilarei. Portanto, alegre est=E1 o meu cora=E7=E3o". (Salmos 16:8) "Os olhos do SENHOR est=E3o sobre os justos, e os seus ouvidos atentos ao seu clamor". (Salmos 34:15)
State Changed From-To: open->closed E-mail of submitter is inactive and I can not tell with the submitter.