Subject: RE: misc/22479: Memory leak in arp
To: Robert Elz <kre@munnari.OZ.AU>
From: Bo Helleskov <bo@helleskov.dk>
List: netbsd-bugs
Date: 08/14/2003 15:54:25
From: Robert Elz [mailto:kre@munnari.OZ.AU]
Sent: 14. august 2003 14:56
To: bo@helleskov.dk
Cc: gnats-bugs@gnats.NetBSD.org; netbsd-bugs@netbsd.org
Subject: Re: misc/22479: Memory leak in arp 


    Date:        Thu, 14 Aug 2003 09:46:32 +0000 (UTC)
    From:        bo@helleskov.dk
    Message-ID:  <20030814094632.E767B11152@narn.netbsd.org>

  | The arp command allocates memory in two places.
  | In line 415 and and line 490, but it never calls free.

But it does exit, that's enough.


  | >How-To-Repeat:
  | Since arp only allocates a low amount of memory (on my machine if
  | was 674 bytes) you need to run it a couple of hundred thousand times
  | to watch how memory start to disappear.

Have you actually observed that happen, or is this just a presumption
of what you believe will happen?

If you've observed memory "disappearing" - what memory is that, and
how was it observed?

´ > I did watch memory "disapearing", but after your email, i've tested
  > it again and im sorry to say that i looked at the wrong counter.
  > so your correct no leak here.

All memory allocated by a program gets released when the program exits.
Calling free() before exit() (except in programs where there might
really be memory leak problems, and everything needs to be accounted for
as part of debugging real bugs) is just a waste of cpu cycles.

  > sorry if this is not a real bug.
  >
  > But how will you know if you have memory leaks ? if you dont do your
  > own accounting how will you know if someting is missing ?
  > and if exit does free memory, where does all this accouting take place ?
  > i find this really interessting, must look into it.

  > i can agree on the subject: "memory leak" was not good, but in lack of
  > english terms it was the best at that time.
  

  | >Fix:
  | I've created a patch that works

If there was a bug that needed fixing here, you'd want to generate your
patch with "diff -u" instead of just "diff".   But there isn't, so it
doesn't matter this time.

  > point taken. 

kre

best wishes,
bo