Editing Finding Memory Leaks

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.

Latest revision Your text
Line 5: Line 5:
== Building Octave ==
== Building Octave ==


Creating a version of Octave which works with an Address Sanitizer is quite simple.  After obtaining the source code for Octave, use the configure script with whatever options you normally build with and add the special option <code>--enable-address-sanitizer-flags</code>.  In addition, it is often very very useful for the backtraces if debugging information is included during the build.  As an example of configuring Octave for finding memory leaks
Creating a version of Octave which works with an Address Sanitizer is quite simple.  After obtaining the source code for Octave, use the configure script with whatever options you normally build with and add the special option "--enable-address-sanitizer-flags".  In addition, it is often very very useful for the backtraces if debugging information is included during the build.  As an example of configuring Octave for finding memory leaks


<syntaxhighlight lang="bash">
  setenv CFLAGS "-ggdb3 -O0 -pipe"
setenv CFLAGS "-ggdb3 -O0 -pipe"
  setenv CXXFLAGS "${CFLAGS}"
setenv CXXFLAGS "${CFLAGS}"
  setenv FFLAGS "${CFLAGS}"
setenv FFLAGS "${CFLAGS}"
  ./configure --prefix=/home/user/local --enable-address-sanitizer-flags -C
./configure --prefix=/home/user/local --enable-address-sanitizer-flags -C
</syntaxhighlight>


==== GUI leaks ====
==== GUI leaks ====


If there is a memory problem, the Address Sanitizer will dump information about the leak, including a backtrace, to stderr.  However, if you are using the GUI it will have redirected stderr so that it no longer shows up in the terminal window from which Octave was launched.  In order to debug the GUI, temporarily undo this redirection by commenting out lines 117-119 in {{path|libgui/qterminal/libqterminal/unix/QUnixTerminalImpl.cpp}}.  The patch to do so is shown below.  Copy this to a file and then execute <code>patch -p1 < dup.patch</code>.
If there is a memory problem, the Address Sanitizer will dump information about the leak, including a backtrace, to stderr.  However, if you are using the GUI it will have redirected stderr so that it no longer shows up in the terminal window from which Octave was launched.  In order to debug the GUI, temporarily undo this redirection by commenting out lines 117-119 in libgui/qterminal/libqterminal/unix/QUnixTerminalImpl.cpp.  The patch to do so is shown below.  Copy this to a file and then execute 'patch -p1 < dup.patch'.


{{file|dup.patch|
  diff -r f50ef29d874e libgui/qterminal/libqterminal/unix/QUnixTerminalImpl.cpp
<syntaxhighlight lang="diff">
  --- a/libgui/qterminal/libqterminal/unix/QUnixTerminalImpl.cpp Thu Sep 14 09:02:07 2017 -0700
diff -r f50ef29d874e libgui/qterminal/libqterminal/unix/QUnixTerminalImpl.cpp
  +++ b/libgui/qterminal/libqterminal/unix/QUnixTerminalImpl.cpp Thu Sep 14 09:40:07 2017 -0700
--- a/libgui/qterminal/libqterminal/unix/QUnixTerminalImpl.cpp Thu Sep 14 09:02:07 2017 -0700
  @@ -114,9 +114,11 @@ void QUnixTerminalImpl::connectToPty()
+++ b/libgui/qterminal/libqterminal/unix/QUnixTerminalImpl.cpp Thu Sep 14 09:40:07 2017 -0700
 
@@ -114,9 +114,11 @@ void QUnixTerminalImpl::connectToPty()
      int fds = m_kpty->slaveFd();
 
    int fds = m_kpty->slaveFd();
  +    /*
      dup2 (fds, STDIN_FILENO);
+    /*
      dup2 (fds, STDOUT_FILENO);
    dup2 (fds, STDIN_FILENO);
      dup2 (fds, STDERR_FILENO);
    dup2 (fds, STDOUT_FILENO);
  +    */
    dup2 (fds, STDERR_FILENO);
 
+    */
      if(!isatty(STDIN_FILENO)) {
          qDebug("Error: stdin is not a tty.");
    if(!isatty(STDIN_FILENO)) {
        qDebug("Error: stdin is not a tty.");
</syntaxhighlight>
}}


After patching the code, build as before with the correct configure options and then proceed normally.  The GUI will run, but the Command Window will now appear back in the terminal window from which you launched Octave.
After patching the code, build as before with the correct configure options and then proceed normally.  The GUI will run, but the Command Window will now appear back in the terminal window from which you launched Octave.
Line 44: Line 38:
The Address Sanitizer is now built in to the Octave executable.  The behavior of the Sanitizer can be controlled with the environment variable '''ASAN_OPTIONS'''.  For example, this is a useful value of ASAN_OPTIONS:
The Address Sanitizer is now built in to the Octave executable.  The behavior of the Sanitizer can be controlled with the environment variable '''ASAN_OPTIONS'''.  For example, this is a useful value of ASAN_OPTIONS:


<syntaxhighlight lang="bash">
  setenv ASAN_OPTIONS "leak_check_at_exit=0:verbosity=1"
setenv ASAN_OPTIONS "leak_check_at_exit=0:verbosity=1"
</syntaxhighlight>


(With recent compilers you may need to use LSAN_OPTIONS variable instead.)
(With recent compilers you may need to use LSAN_OPTIONS variable instead.)
Line 56: Line 48:
== Finding Leaks ==
== Finding Leaks ==


Now that Octave has been built with the Address Sanitizer, and the Sanitizer itself has been configured by its environment variable, the next step is to launch Octave (typically <code>./run-octave</code>), and execute code.  This might mean running the default set of tests that come with Octave, <code>__run_test_suite__</code>.  It could mean a particular function, "test ls".  Or it could be simply running your own scripts, commands, etc. to see if a leak is triggered.  If a memory error is detected the Sanitizer will dump a summary and backtrace to stderr.  Make a new bug report at http://bugs.octave.org and include the backtrace in the report.
Now that Octave has been built with the Address Sanitizer, and the Sanitizer itself has been configured by its environment variable, the next step is to launch Octave (typically ./run-octave), and execute code.  This might mean running the default set of tests that come with Octave, "__run_test_suite__".  It could mean a particular function, "test ls".  Or it could be simply running your own scripts, commands, etc. to see if a leak is triggered.  If a memory error is detected the Sanitizer will dump a summary and backtrace to stderr.  Make a new bug report at [[bugs.octave.org]] and include the backtrace in the report.
 
 
[[Category:Development]]
Please note that all contributions to Octave may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see Octave:Copyrights for details). Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel Editing help (opens in new window)

Templates used on this page: