From nobody@FreeBSD.org Fri Aug 16 11:52:27 2002 Return-Path: Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5308337B400 for ; Fri, 16 Aug 2002 11:52:27 -0700 (PDT) Received: from www.freebsd.org (www.FreeBSD.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED43A43E6A for ; Fri, 16 Aug 2002 11:52:26 -0700 (PDT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.12.4/8.12.4) with ESMTP id g7GIqQOT053008 for ; Fri, 16 Aug 2002 11:52:26 -0700 (PDT) (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.12.4/8.12.4/Submit) id g7GIqQJe053007; Fri, 16 Aug 2002 11:52:26 -0700 (PDT) Message-Id: <200208161852.g7GIqQJe053007@www.freebsd.org> Date: Fri, 16 Aug 2002 11:52:26 -0700 (PDT) From: Harsha Bellur To: freebsd-gnats-submit@FreeBSD.org Subject: Memory Leak in FreeBSD X-Send-Pr-Version: www-1.0 >Number: 41717 >Category: kern >Synopsis: Memory Leak in FreeBSD >Confidential: no >Severity: critical >Priority: high >Responsible: bms >State: closed >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Aug 16 12:00:04 PDT 2002 >Closed-Date: Wed Jun 16 06:11:04 GMT 2004 >Last-Modified: Wed Jun 16 06:11:04 GMT 2004 >Originator: Harsha Bellur >Release: ??? Freebsd version used in RTEMS 4.5 >Organization: >Environment: RTEMS 4.5 >Description: | | ---------- ---------- | | | | | ETH | | NODE A | PT-PT LINK | NODE B |----------| 172.16.40.1 | |---------------------- | | | ---------- ---------- | | Node A IP : 172.16.17.124 NODE B IP : 172.16.40.122 NODE A adds NODE B's IP as its default gateway Here's the routing table for NODE B Destination Gateway/Mask/Hw Flags Refs Use Interface default 172.16.40.122 UGSW 1744 289 serial0 127.0.0.1/0 127.0.0.1 UHb 0 0 lo0 172.16.17.124/32 127.0.0.1 UH 0 0 lo0 172.16.40.0/24 172.16.40.122 UGW 1 7 serial0 172.16.40.122/32 172.16.17.124 UH 1746 0 serial0 TEST EXECUTED: . NODE B is reset every 30-40 seconds. Everytime the PT-PT interface goes down NODE A deletes the default gateway and the routes associated with it and Adds it when the interface is back up and running PROBLEM REPORT: This process of adding and deleting routes is causing memory loss in NODE A I found out the places in the freebsd code where the memory is allocated but not freed. (which may be of some help) Memory leak doesnot happen everytime these lines of code are executed. 1. route.c rtrequest() makeroute: R_Malloc(rt, struct rtentry *, sizeof(*rt)); if (rt == 0) senderr(ENOBUFS); Bzero(rt, sizeof(*rt)); 2. route.c rt_setgate() if (rt->rt_gateway == 0 || glen > ROUNDUP(rt->rt_gateway->sa_len)) { old = (caddr_t)rt_key(rt); R_Malloc(new, caddr_t, dlen + glen); if (new == 0) return ENOBUFS; 3. in.c in_control() case SIOCSIFDSTADDR: if (p && (error = suser(p)) != 0) return error; if (ifp == 0) return (EADDRNOTAVAIL); if (ia == (struct in_ifaddr *)0) { ia = (struct in_ifaddr *) malloc(sizeof *ia, M_IFADDR, M_WAITOK); if (ia == (struct in_ifaddr *)NULL) return (ENOBUFS); >How-To-Repeat: NODE B is reset every 30-40 seconds. Everytime the PT-PT interface goes down NODE A deletes the default gateway and the routes associated with it and Adds it when the interface is back up and running >Fix: >Release-Note: >Audit-Trail: Responsible-Changed-From-To: freebsd-bugs->bms Responsible-Changed-By: bms Responsible-Changed-When: Tue 25 Nov 2003 08:40:08 PST Responsible-Changed-Why: I'm in hoover up network PRs mode. I'll look into this. It is possible this problem has since been corrected since we presently have at least 3 pairs of eyes looking at this code. http://www.freebsd.org/cgi/query-pr.cgi?pr=41717 State-Changed-From-To: open->analyzed State-Changed-By: bms State-Changed-When: Wed Jun 16 06:08:44 GMT 2004 State-Changed-Why: Point 1 is misleading. R_Zalloc() is a macro which stores the address of the zeroed, allocated memory in 'rt'. If 'rt' is 0, senderr() returns. There are no other allocations directly made here. Point 2 is also misleading. R_Malloc() is a macro which stores the address of the allocated memory in 'new'. If 'new' is 0, then rt_setgate() returns. There are no other allocations made in this function; it is possible, however, that something isn't getting freed, but I haven't gone this far down the line. Point 3 is also misleading. This is a fairly routine checked allocation for a point-to-point interface. I'm not familiar with the version of the stack in use within RTEMS; the above commentary is based on FreeBSD -CURRENT as of this date. http://www.freebsd.org/cgi/query-pr.cgi?pr=41717 State-Changed-From-To: analyzed->closed State-Changed-By: bms State-Changed-When: Wed Jun 16 06:10:50 GMT 2004 State-Changed-Why: We don't have any debugging traces (coredumps, dmesg etc) and they aren't applicable to FreeBSD as this was reported from an RTEMS fork. Whilst we're grateful that the problem has been pointed out, we can't identify what the problem is because there is simply no information, and in any event is not likely to be relevant to the Project now anyway. http://www.freebsd.org/cgi/query-pr.cgi?pr=41717 >Unformatted: