From bug-request at octave dot org Fri Jan 14 15:56:44 2005 Subject: Re: Serious memory leak in octave (this may be a duplicate bug report) From: Erik de Castro Lopo To: bug at octave dot org Date: Sat, 15 Jan 2005 08:59:51 +1100 On Fri, 14 Jan 2005 15:13:45 -0600 Dan Nessett wrote: > This may be a duplicate bug report. I got tangled up in emacs using > bug_report and I don=81=B9t know if it sent the email. >=20 > When I attempt to display a vector of 800,000 elements, octave starts > gobbling up virtual memory. The sequence of commands is: >=20 > p=3Dlinspace(1,80000,800000)=81=B9; > p >=20 > This is a test sequence. I discovered the bug when using plot() to plot t= wo > 800,000 vectors against each other. >=20 > As you can see from the printout of =81=B3top=81=B2 below, octave consume= s about 19 > 1/2 minutes of cpu time processing this set of commands and its virtual > space grows to 2.53 Gbytes. The printout from top is just after octave > finishes the second command.=20 The top command is a very blunt tool for determining whether a program has a memory leak or not. May versions of top include the size of libx/libstdc++ in the calculation of the size of the program. > I=81=B9m not a Mac OS X/Darwin/NetBSD expert, but it appears that octave = is > grabbing swap space and not releasing it. This is a classic symptom of a > memory leak. If I run two copies of octave and execute the same sequence = of > commands, my Mac comes to its knees. The Finder goes out to lunch and I h= ave > to force reboot the system with the power switch. >=20 > My only suggestion on a fix is to use Purify or some other memory leak > detection software. On x86 Linux, using valgrind (unfortunately only available for x86 Linux)=20 I ran the following commands: LinuxPrompt> valgrind --leak-check=3Dyes octabe OctavePrompt> p =3D linspace(1,80000, 80000); OctavePrompt> clear p OctavePrompt> exit and the valgrind summary showed: =3D=3D10773=3D=3D LEAK SUMMARY: =3D=3D10773=3D=3D definitely lost: 394 bytes in 13 blocks. =3D=3D10773=3D=3D possibly lost: 1081244 bytes in 438 blocks. =3D=3D10773=3D=3D still reachable: 10845261 bytes in 20991 blocks. =3D=3D10773=3D=3D suppressed: 200 bytes in 1 blocks. =3D=3D10773=3D=3D Reachable blocks (those to which a pointer was found)= are not shown. Funnily enough, valgrind gives exactly the same report if I exit the program as soon as I get the octave prompt. This means that while there *may* be some memory leaks in octave's initialisation/shutdown code, there is no memory leak in the simple data operation above. Valgrind also reports a bunch of other errors, like this: =3D=3D10780=3D=3D Invalid read of size 1 =3D=3D10780=3D=3D at 0x1B906540: strchr (mac_replace_strmem.c:133) =3D=3D10780=3D=3D by 0x1D1EFABE: tilde_expand (tilde.c:193) =3D=3D10780=3D=3D by 0x1D1DEDED: _rl_read_init_file (bind.c:747) =3D=3D10780=3D=3D by 0x1D1DED5B: rl_read_init_file (bind.c:732) =3D=3D10780=3D=3D Address 0x1D68FEA0 is 0 bytes inside a block of size= 13 free'd =3D=3D10780=3D=3D at 0x1B907460: free (vg_replace_malloc.c:153) =3D=3D10780=3D=3D by 0x1D1DEF1A: _rl_read_init_file (bind.c:785) =3D=3D10780=3D=3D by 0x1D1DED79: rl_read_init_file (bind.c:725) =3D=3D10780=3D=3D by 0x1D1DECF2: rl_re_read_init_file (bind.c:689) In my experience, these are really well worth fixing because they are often the cause of weird/elusive little bugs. HTH, Erik --=20 +-----------------------------------------------------------+ Erik de Castro Lopo nospam at mega-nerd dot com (Yes it's valid) +-----------------------------------------------------------+ "The object-oriented model makes it easy to build up programs by=20 accretion. What this often means, in practice, is that it provides=20 a structured way to write spaghetti code." -- Paul Graham ------------------------------------------------------------- Octave is freely available under the terms of the GNU GPL. Octave's home on the web: http://www.octave.org How to fund new projects: http://www.octave.org/funding.html Subscription information: http://www.octave.org/archive.html -------------------------------------------------------------