help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: octave memory allocation problem ?


From: Joao Cardoso
Subject: Re: octave memory allocation problem ?
Date: Wed, 26 Apr 1995 00:27:06 +0200 (MET DST)

Hi,

                        I APOLOGIZE.

        *** Matlab's "load" does not work as I said. ***

In the process of converting my "Matlab v4.0 for Windows" files to Octave
I get confused (to be kind with myself...).

Now, about the memory leak, here is a description of the problem I found.

It seems to be related with function invocation (at least).

My system is a SCO 2.0., "i486-unknown-sco3.2v4.0"
I did not run the tests when I build octave, as I have no DejaGnu.

I also notice this problem with recursion, using the supplied recursion-1.m
in the distribution test/recursion directory.

The original problem:
        
        octave
        Octave, version 1.1.1.
        Copyright (C) 1992, 1993, 1994, 1995 John W. Eaton.
        This is free software with ABSOLUTELY NO WARRANTY.
        For details, type `warranty'.
        
        octave:1> type popo
        popo is a user-defined function
        function a = popo (file)
          eval (["load ", file, ";"])
          a = b;
        endfunction
        octave:2> system("ps -l"| fgrep octave")
         20 S    200   335   298  0  26 20    8fc    58e 748  f014abfa  p1      
 0:00 octave
        octave:3> b=rand(100);                           ^^^
        octave:4> system("ps -l | fgrep octave")
         20 S    200   335   298  1  26 20    8fc    58e 828  f014a2fa  p1      
 0:01 octave
        octave:5> save caca b                            ^^^
        octave:6> clear
        octave:7> system("ps -l |       fgrep octave")
         20 S    200   335   298  1  26 20    8fc    58e 748  f014a2fa  p1      
 0:03 octave
        octave:8> a=popo("caca");                        ^^^
        octave:9> system("ps -l | fgrep octave")
         20 S    200   335   298  5  26 20    8fc    58e 872  f014a2fa  p1      
 0:06 octave
        octave:10> clear -x                              ^^^
        octave:11> system("ps -l | fgrep octave")
         20 S    200   335   298  1  26 20    8fc    58e 872  f014a2fa  p1      
 0:06 octave
        octave:12> clear *                               ^^^
        octave:13> system("ps -l | fgrep octave")
         20 S    200   335   298  1  26 20    8fc    58e 792  f014a2fa  p1      
 0:06 octave
        octave:14> clear -x                              ^^^
        octave:15> system("ps -l | fgrep octave")
         20 S    200   335   298  1  26 20    8fc    58e 792  f014a2fa  p1      
 0:06 octave
                                                         ^^^
        octave:16> for i=1:10; a=popo("caca"); clear -x *;system("ps -l | fgrep 
octave"); end
                                                        
         20 S    200   335   298 81  26 20    8fc    58e 836  f014a2fa  p1      
 0:09 octave
         20 R    200   335   298 62  91 20    8fc    58e 884            p1      
 0:12 octave
         20 R    200   335   298 40  80 20    8fc    58e 932            p1      
 0:14 octave
         20 R    200   335   298 81 100 20    8fc    58e 996            p1      
 0:17 octave
         20 R    200   335   298 81 100 20    8fc    58e1040            p1      
 0:19 octave
         20 R    200   335   298 79  99 20    8fc    58e1084            p1      
 0:22 octave
         20 R    200   335   298 58  89 20    8fc    58e1128            p1      
 0:24 octave
         20 R    200   335   298 41  80 20    8fc    58e1172            p1      
 0:27 octave
         20 R    200   335   298 81 100 20    8fc    58e1216            p1      
 0:30 octave
         20 R    200   335   298 81 100 20    8fc    58e1260            p1      
 0:32 octave
                                                        ^^^^
        octave:18> who -l
        
Notice that memory is incremented in steps of 44 pages, occasionally more.
With an array with the double size, rand(100,200) the behavior is the same, as
well as with an array of 500x500 (a five Megabyte file). This means that the
problem is not related with file size, but with function invocation.

The amount of memory grabbed and not released depends on what is called:
        
        octave:1> system("ps -l | fgrep octave")
         20 S    200   923   298  3  26 20    8fc    58e 676  f014933a  p1      
 0:00 octave
        octave:2> for i=1:5000; po1(i);end
        octave:3> system("ps -l | fgrep octave")
         20 R    200   923   298 15  67 20    8fc    58e 764            p1      
 0:28 octave
        octave:5> type po1                               ^^^
        po1 is a user-defined function
        function y = po1 (x)
          y = x;
        endfunction

With 
        octave:5> type po1
        po1 is a user-defined function
        function y = po1 (x)
          y = 1;
        endfunction

we have the same behavior, as well as with
        
        function po1 ()
        endfunction

Now: is this a problem, a feature, a bug, something we can live with, a problem
with my system libraries, or what?


Again, my apologies,

Joao Cardoso
INESC
R. Jose Falcao 110
4000 PORTO
PORTUGAL

e-mail: address@hidden
tel:    + 351 2 2094300
fax:    + 351 2 2008487 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]