From: SourceForge.net <no...@so...> - 2003-06-23 17:34:56
|
Bugs item #556830, was opened at 2002-05-16 08:55 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112694&aid=556830&group_id=12694 Category: agent Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: seg fault when walk ifPhysAddress Initial Comment: Hi, I am using net-snmp-5.0.1 with SunOS 5.8. I get a Segmentation fault when I select OID .1.3.6.1.2.1.2.2.1.6.1 in the tkmib browser and click "walk". The core dump gives me the following information: Line of the fault: 1313 case IFPHYSADDRESS: 1314 *var_len = ifstat.ifPhysAddress.o_length; -> 1315 (void) memcpy(return_buf, ifstat.ifPhysAddress.o_bytes, *var_len); 1316 return (u_char *) return_buf; 1317 case IFADMINSTATUS: 1318 long_return = (u_long) ifstat.ifAdminStatus; 1319 return (u_char *) & long_return; backtrace: Program received signal SIGSEGV, Segmentation fault. 0xff1814d4 in seg7 () from /usr/platform/SUNW,Ultra- Enterprise/lib/libc_psr.so.1 (gdb) backtrace #0 0xff1814d4 in seg7 () from /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1 #1 0xff180804 in blalign () from /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1 #2 0x40d64 in var_ifEntry (vp=0x107368, name=0x2afa58, length=0x2afa48, exact=0, var_len=0xffbed544, write_method=0xffbed540) at mibII/interfaces.c:1315 #3 0x65888 in netsnmp_old_api_helper (handler=0xb, reginfo=0x13d928, reqinfo=0x2aeef0, requests=0x2abef0) at old_api.c:288 #4 0x2de38 in netsnmp_call_next_handler (current=0x13c2a0, reginfo=0x13d928, reqinfo=0x2aeef0, requests=0x2abef0) at agent_handler.c:324 #5 0x6335c in netsnmp_bulk_to_next_helper (handler=0x13c2e0, reginfo=0x13d928, reqinfo=0x2aeef0, requests=0x2abef0) at bulk_to_next.c:84 #6 0x2d0f8 in netsnmp_call_handlers (reginfo=0x13d928, reqinfo=0x2aeef0, requests=0x2abef0) at agent_handler.c:293 #7 0x26478 in handle_var_requests (asp=0x2ac7a0) at snmp_agent.c:1878 #8 0x276c4 in handle_pdu (asp=0x2ac7a0) at snmp_agent.c:2573 #9 0x272e0 in netsnmp_handle_request (asp=0x2ac7a0, status=0) at snmp_agent.c:2426 #10 0x25784 in handle_snmp_packet (op=1, session=0x2abf38, reqid=13350286, pdu=0x2ac4b0, magic=0x2ac7a0) at snmp_agent.c:1364 #11 0x89b68 in _sess_process_packet (sessp=0x2aeec0, sp=0x2abf38, isp=0x2af998, transport=0x2ac4b0, opaque=0x0, olength=16, packetptr=0x2df270 "0+\002 \001", length=45) at snmp_api.c:5013 #12 0x8a934 in _sess_read (sessp=0x2aeec0, fdset=0x2df270) at snmp_api.c:5388 #13 0x8a95c in snmp_sess_read (sessp=0x2aeec0, fdset=0xffbedfe0) at snmp_api.c:5407 #14 0x89ccc in snmp_read (fdset=0xffbedfe0) at snmp_api.c:5065 #15 0x2361c in receive () at snmpd.c:916 #16 0x22ff4 in main (argc=0, argv=0xffbee5e4) at snmpd.c:775 And the value var_len is: *varlen = 1000000000 !!! I tried to run the program step by step, but I haven't been able to find anything else yet. Regards, German. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-23 10:34 Message: Logged In: NO I've debugged a Solaris 6 version of the code and it too is returning 64-bit values for ifSpeed from the kstat functions. I didn't want to change the size of ifSpeed in the mib2_ifEntry structure, so I decided to pass getKstat a temporary 64-bit variable and then type-cast it to 32-bits when assigning to ifSpeed. This will work until we get to 10 Gigabit interfaces, but then ifSpeed is still a 32-bit variable in the MIB definition anyway. Here is my code snipet for kernel_sunos.c static int getif(mib2_ifEntry_t *ifbuf, size_t size, req_e req_type, mib2_ifEntry_t *resp, size_t *length, int (*comp)(void *, void *), void *arg) { : : : : : : : uint64_t tmpSpeed; : : : : : : : : /* Use a temp variable for ifSpeed because it is 32-bits in the ifp * * structure but the kstat routines are returning 64-bit values * * which was overwriting ifPhysAddress.o_length * * Convert the 64-bit tmpSpeed to 32-bits when assignign to ifSpeed * * * * This was tested on Solaris 2.6 and Solaris 8 only * * Mark Freiberger, 06/23/2003 */ if ((getKstat(ifrp->ifr_name, "ifspeed", &tmpSpeed) == 0) && (tmpSpeed != 0)) { /* * check for SunOS patch with half implemented ifSpeed */ ifp->ifSpeed = (Gauge) tmpSpeed; if (ifp->ifSpeed < 10000) { ifp->ifSpeed *= 1000000; } } else if (getKstat(ifrp->ifr_name, "ifSpeed", &tmpSpeed) == 0) { /* * this is good */ ifp->ifSpeed = (Gauge) tmpSpeed; } switch (ifrp->ifr_name[0]) { : : : : : : : : I removed the two lines in my previous posting that initialized ifp->ifPhysAddress. I've tested this on Solaris 2.6 and Solaris 8 and it works fine. I don't have any other Solaris versions, so can't test it there. Please send questions or comments to mar...@ed... since I'm having trouble getting mail from the net-snmp users group list. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-20 14:41 Message: Logged In: NO I added the first two lines below in kernel_sunos5.c::getif from netsnmp 5.0.7. ifp->ifPhysAddress.o_length = 0; ifp->ifPhysAddress.o_bytes[0] = 0; if (getMibstat(MIB_IP_NET, &Media, sizeof(mib2_ipNetToMediaEntry_t), GET_EXACT, &Name_cmp, ifrp) == 0) { ifp->ifPhysAddress = Media.ipNetToMediaPhysAddress; } While not the final solution, my agent is not crashing. We really need to figure out how to handle the 64-bit to 32-bit problem in mib2_ifEntry -> ifSpeed. Mark Freiberger, mar...@ed... P.S. My subscription to netsnmp mailing lists is not working. Please send any questions/comments directly to me at the address above. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-20 13:06 Message: Logged In: NO I've run across this and can confirm the information below. I also have figured out the exact circumstance that this occurs. The root problem is that a Gauge is 32 bits, get getKstat is reading ifSpeed for some interfaces as int64. That we know. For instance, an hme interface has a speed of 1000000000. So, ifPhysAddress.o_length is getting overwritten. Fortunately, when the ifPhysAddress is set, it erases the error. However, in certain cases, there is no ifPhysAddress for an hme interface (in my case, the status in ifOperStatus = down, ifAdminStatus = down and ifconfig -a shows: hme0: flags=19000842<BROADCAST,RUNNING,MULTICAST,IPv4,NOFAILOVER,FAILED> mtu 0 index 2 inet 0.0.0.0 netmask 0 groupname ipmp_group ). I know this because I ran the Solaris agent and it worked fine. So in this case, ifPhysAddress is not getting set in kernel_sunos5.c::getif ==> if (getMibstat(MIB_IP_NET, &Media, sizeof(mib2_ipNetToMediaEntry_t), GET_EXACT, &Name_cmp, ifrp) == 0) { ifp->ifPhysAddress = Media.ipNetToMediaPhysAddress; } and the ifSpeed overflow into ifPhysAddress.o_length remains and kills the program in the memcpy in interfaces.c::var_ifEntry. My question is why is getKstat being called for ifSpeed when the switch statements right after that also set ifSpeed? Can we get around the problem by commenting out the getKstat call for ifSpeed? Another work-around would be to initialize ifPhysAddress before the loop that tries to find it. The real answer is to make ifSpeed 64 bits (or convert the 64-bit value to 32-bits). Mark Freiberger, mar...@ed... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-10 07:36 Message: Logged In: NO Program received signal SIGSEGV, Segmentation fault. 0xff0c0b74 in seg2 () from /usr/platform/SUNW,Ultra- 4/lib/libc_psr.so.1 (gdb) backtrace #0 0xff0c0b74 in seg2 () from /usr/platform/SUNW,Ultra- 4/lib/libc_psr.so.1 #1 0xff0c06dc in blalign () from /usr/platform/SUNW,Ultra- 4/lib/libc_psr.so.1 #2 0xff2936ac in var_ifEntry (vp=0xffbfec08, name=0x5b5cc18, length=0x10, exact=99994624, var_len=0xffbfec04, write_method=0xff396258) at mibgroup/mibII/interfaces.c:1321 #3 0xff34797c in netsnmp_old_api_helper (handler=0xb, reginfo=0x2e6b8, reqinfo=0x94068, requests=0x94668) at old_api.c:288 #4 0xff381510 in netsnmp_call_handler (next_handler=0x2cc78, reginfo=0x2e6b8, reqinfo=0x94068, requests=0x94668) at agent_handler.c:329 #5 0xff38136c in netsnmp_call_handlers (reginfo=0x2e6b8, reqinfo=0x94068, requests=0x94668) at agent_handler.c:298 #6 0xff378f84 in handle_var_requests (asp=0x93ef0) at snmp_agent.c:1997 #7 0xff37a41c in handle_pdu (asp=0x93ef0) at snmp_agent.c:2705 #8 0xff379fa4 in netsnmp_handle_request (asp=0x93ef0, status=0) at snmp_agent.c:2552 #9 0xff378008 in handle_snmp_packet (op=1, session=0x93f78, reqid=570882731, pdu=0x93e58, magic=0x93ef0) at snmp_agent.c:1452 #10 0xff1b7024 in _sess_process_packet (sessp=0xbb8c0, sp=0x93f78, isp=0x93f40, transport=0x93e58, opaque=0x0, olength=16, packetptr=0xc4688 "0+\002\001", length=45) at snmp_api.c:5052 #11 0xff1b7e9c in _sess_read (sessp=0xbb8c0, fdset=0xc4688) at snmp_api.c:5450 #12 0xff1b84d4 in snmp_sess_read (sessp=0xbb8c0, fdset=0xc4688) at snmp_api.c:5469 #13 0xff1b742c in snmp_read (fdset=0xffbff648) at snmp_api.c:5104 #14 0x13620 in receive () at snmpd.c:1107 #15 0x126cc in main (argc=60001, argv=0xffbffc3c) at snmpd.c:949 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-10 07:25 Message: Logged In: NO Same thing started happening here after applying the latest Solaris9 patch bundle. Before it worked fine. Net-snmp 5.0.8 and Solaris9. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-17 03:39 Message: Logged In: NO It seems that the problem is when setting ifSpeed with the function getKstat in kernel_sunos5.c. My agent is assuming that the value is a 64 bits integer (KSTAT_DATA_UINT64), but this is a Gauge and in my /usr/include/inet/mib2.h header a Gauge is only a 32 bits integer. Maybe this should not be defined: #ifdef KSTAT_DATA_INT32 /* Solaris 2.6 and up */ but where is it defined? I can't find this macro anywhere! Any help will help, German. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112694&aid=556830&group_id=12694 |