octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #47372] memory leaks in octave-link, octave-qt


From: Rik
Subject: [Octave-bug-tracker] [bug #47372] memory leaks in octave-link, octave-qt-link, octave-mutex
Date: Wed, 09 Mar 2016 18:34:39 +0000
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0

URL:
  <http://savannah.gnu.org/bugs/?47372>

                 Summary: memory leaks in octave-link, octave-qt-link,
octave-mutex
                 Project: GNU Octave
            Submitted by: rik5
            Submitted on: Wed 09 Mar 2016 10:34:37 AM PST
                Category: Interpreter
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Performance
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: dev
        Operating System: GNU/Linux

    _______________________________________________________

Details:

gcc has a fast, lightweight memory checker that can be enabled with compiler
flags.  To check Octave, I did the following (this is for a csh shell).


setenv CFLAGS "-g -O0 -pipe"
setenv CXXFLAGS "${CFLAGS}"
setenv FFLAGS "${CFLAGS}"
./configure --enable-address-sanitizer-flags --disable-jit --without-opengl
--disable-docs
make


There are numerous problems in the OpenGl libraries so they had to be
disabled.  Likewise, the build won't complete without --disable-docs because
the build system uses run-octave to generate images and that requires OpenGl
libraries at the moment.

With the instrumented version of Octave in place, I ran


./run-octave -f --no-gui-libs
exit


This produces a clean report.  There are no memory leaks when using the CLI
binary which is not linked against Qt.  Next, I tried


./run-octave -f --no-gui
exit


This produces a list of leaks which I have attached as leak.log.  In general,
the leaks appear valid.  The constructors for octave-link, octave-qt-link,
octave-mutex use the new operator to initialize some member variables.  But it
appears that the destructors are empty functions (some of them virtual as if
it was expected that they might be overriden) which never free this allocated
memory.  It should be relatively easy to fix these.

Finally, I can't run the GUI at all because there is an immediate memory leak
in the octave binary which is designed to switch between running octave-gui or
octave-cli.


./run-octave -f

=================================================================
==20003==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 80 byte(s) in 1 object(s) allocated from:
    #0 0x7f75e3c94a32 in operator new[](unsigned long)
(/usr/lib/x86_64-linux-gnu/libasan.so.2+0x99a32)
    #1 0x4055c4 in main src/main.cc:449
    #2 0x7f75e2a58a3f in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x20a3f)

Indirect leak of 54 byte(s) in 1 object(s) allocated from:
    #0 0x7f75e3c94a32 in operator new[](unsigned long)
(/usr/lib/x86_64-linux-gnu/libasan.so.2+0x99a32)
    #1 0x40539b in strsave src/main.cc:420
    #2 0x405a93 in main src/main.cc:520
    #3 0x7f75e2a58a3f in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x20a3f)

SUMMARY: AddressSanitizer: 134 byte(s) leaked in 2 allocation(s).


I was working from revision 21419:13415264b9f8 so all of the line numbers are
accurate for that tip.





    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Wed 09 Mar 2016 10:34:37 AM PST  Name: leak.log  Size: 9kB   By: rik5

<http://savannah.gnu.org/bugs/download.php?file_id=36583>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?47372>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

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