Re: Memory leaks in Octave

[Rik]

On 09/14/2017 07:31 PM, Dmitri A. Sergatskov wrote:

On Thu, Sep 14, 2017 at 12:32 PM, Rik <address@hidden> wrote:

The development branch of Octave has switched away from Valgrind (slow) to
using a fast, lightweight memory checker (Address Sanitizer) which is built
in to the code.  It is very easy to do as there is a configure option,
"--enable-address-sanitizer-flags", which sets everything up.  Because this
is new and relatively unknown, I wrote a Wiki entry for it at
http://wiki.octave.org/Finding_Memory_Leaks.

Running '__run_test_suite__' seems to work.  But I assume there are still
plenty of ways to cause problems because I found two within 5 minutes just
by trying a few commands.  Maybe I was extraordinarily unlucky, but it
would be useful if others could build with the Address Sanitizer and then
run operate normally, i.e., use it for regular use and run your own scripts
through it to see if it provokes any errors.

​My builds with gcc7.1.1 and ASAN pretty much fail due to

​

 AddressSanitizer: stack-use-after-scope

​that I could not figure out how to suppress.

This error pops up everywhere ("plot​" is probably the most important since

it means I cannot build docs). The trace always points to

<<<<

#0 0x7feda7f964b9  (/lib64/libasan.so.4+0x394b9)
    #1 0x7feda2e09a0a in octave_set_signal_handler_internal ../liboctave/wrappers/signal-wrappers.c:368
    #2 0x7feda2e09c15 in octave_set_signal_handler_by_name ../liboctave/wrappers/signal-wrappers.c:384
    #3 0x7feda69c1e1c in octave::set_signal_handler(char const*, void (*)(int), bool) ../libinterp/corefcn/sighandlers.cc:420
    #4 0x7feda69c269f in octave::catch_interrupts() ../libinterp/corefcn/sighandlers.cc:565
>>>>

But then at the end it says:

<<<<

Address 0x7fed76583cf0 is located in stack of thread T6 (QThread) at offset 288 in frame
    #0 0x7feda2e09858 in octave_set_signal_handler_internal ../liboctave/wrappers/signal-wrappers.c:344

  This frame has 2 object(s):
    [32, 184) 'act'
    [224, 376) 'oact' <== Memory access at offset 288 partially overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)

>>>>

which kind of suggests that it may be false positive...

 

I'm building with gcc-5.4.0 and I don't see this. 

--Rik