Re: sparc64/114349: When executing snmpd it immediately stops with a segmentation fault in disman/ev

The following reply was made to PR sparc64/114349; it has
been noted by GNATS.

From: Patrick Donnelly <phdoceancomputer.com>
To: bug-followupFreeBSD.org,
 freebsd-lists-1thismonkey.com
Cc:  
Subject: Re: sparc64/114349: When executing snmpd it
immediately stops with a segmentation fault in
disman/event/mteObjects.c
Date: Mon, 24 Mar 2008 13:08:17 -0400

 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
 phdoceancomputer.com
 
_______________________________________________
freebsd-sparc64freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-sparc
64
To unsubscribe, send any mail to
"freebsd-sparc64-unsubscribefreebsd.org"