Memory leak revisited (NJAMD + octave)

[Dmitri A. Sergatskov]

I was playing with NJAMD (http://fscked.org/proj/njamd.shtml) trying to find the
source of memory leak which was reported by David MacKay some time ago.
That was my first experience with njamd so perhaps someone with more experience 
can
give me some help here. Anyway, here what I did and what I saw:

address@hidden octave]$ export LD_PRELOAD=libnjamd.so
address@hidden octave]$ octave
NJAMD/free: Address 0x0 not from malloc
        called from /lib/tls/libc.so.6(setlocale+0x1dc)[0x185cbc]
        called from /usr/lib/libreadline.so.4(_rl_init_eightbit+0x30)[0x3a2090]
        called from /usr/lib/libreadline.so.4[0x38daea]
GNU Octave, version 2.1.57 (i686-pc-linux-gnu).
Copyright (C) 2004 John W. Eaton.

... (skipped header)...

NJAMD/free: Address 0x0 not from malloc
        called from /lib/tls/libc.so.6(setlocale+0x404)[0x6fbee4]
        called from sh(set_default_locale+0x1b)[0x808cf9b]
        called from sh(main+0x57)[0x805a817]
NJAMD/free: Address 0x0 not from malloc
        called from gnuplot[0x807dbc5]
        called from gnuplot[0x8084d31]
        called from /lib/tls/libc.so.6(__libc_start_main+0xe4)[0x6f2ad4]
NJAMD/free: Address 0x0 not from malloc
        called from gnuplot[0x807dbd3]
        called from gnuplot[0x8084d31]
        called from /lib/tls/libc.so.6(__libc_start_main+0xe4)[0x6f2ad4]
NJAMD/free: Address 0x0 not from malloc
        called from gnuplot[0x80ee034]
        called from gnuplot[0x80eed5a]
        called from gnuplot[0x8084ef2]
NJAMD/free: Address 0x0 not from malloc
        called from gnuplot[0x80eed6f]
        called from gnuplot[0x8084ef2]
        called from /lib/tls/libc.so.6(__libc_start_main+0xe4)[0x6f2ad4]
octave:1> test0
__nj_overflow_alloc/mprotect: Cannot allocate memory

address@hidden octave]$

        test0 is David's script which demonstrated memory leak.
        It took only a couple second before octave got killed.
        There is no core file.

        Playing around I found that most strings operations would cause the 
same error
        (__nj_overflow_alloc/mprotect: Cannot allocate memory). The simplest 
perhaps
        would be:

octave:1> num2str(1)
__nj_overflow_alloc/mprotect: Cannot allocate memory

        Digging dipper into num2str I found that consecutive call to strcat and 
repmat
        causes this error:

octave:1> a="A"
a = A
octave:2> b=repmat(a,1,1)
b = A
octave:3> b1=repmat(a,1,1)
b1 = A
octave:4> b2=repmat(a,1,1)
b2 = A
octave:5> c=strcat(a,b)
__nj_overflow_alloc/mprotect: Cannot allocate memory

address@hidden octave]$

        (b1 and b2 here just to demonstrate that repmat alone does not kill 
octave)
        We can reverse repmat and strcat:

octave:1> a="A"
a = A
octave:2> b="B"
b = B
octave:3> c=strcat(a,b)
c = AB
octave:4> d=repmat(a,1,1)
__nj_overflow_alloc/mprotect: Cannot allocate memory

address@hidden octave]$

        Reducing strcat and repmat to their essentials will not make the error:

octave:1> a="A"
a = A
octave:2> b=setstr(kron (ones(1,1),toascii(a)))
b = A
octave:3> c=[a,b]
c = AA
octave:4> c=strcat(a,b)
c = AA
octave:5>

        FFT does have another problem:

octave:1> x=rand(100);
octave:2> y=x';
octave:3> z=ifft(x)
panic: Segmentation fault -- stopping myself...
Segmentation fault (core dumped)
address@hidden octave]$

        Linear algebra:

octave:1> x=rand(1000);
octave:2> y=x'*x;
panic: Segmentation fault -- stopping myself...
Segmentation fault (core dumped)

octave:1> x=rand(1000);
octave:2> a=linspace(1,1000,1000);
octave:3> y=x\a';
panic: Segmentation fault -- stopping myself...
Segmentation fault (core dumped)

        Those do produce a core file (actually 4 different cores), and hopefully
        recompiling octave with -g will give some clue here.

Sincerely,

Dmitri.







-------------------------------------------------------------
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
-------------------------------------------------------------