Memory leaks in Octave

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Memory leaks in Octave

Rik-4
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.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Memory leaks in Octave

Dmitri A. Sergatskov
On Thu, Sep 14, 2017 at 12:32 PM, Rik <[hidden email]> 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...

 
--Rik


​Dmitri.
--

Reply | Threaded
Open this post in threaded view
|

Re: Memory leaks in Octave

Rik-4
On 09/14/2017 07:31 PM, Dmitri A. Sergatskov wrote:
On Thu, Sep 14, 2017 at 12:32 PM, Rik <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Memory leaks in Octave

siko1056
Rik-4 wrote
>
> Dmitri A. Sergatskov wrote
>> ​My builds with gcc7.1.1 and ASAN pretty much fail
> I'm building with gcc-5.4.0 and I don't see this.

My experience using "gcc-7 (SUSE Linux) 7.1.1 20170607" was also bad.  Lots
of linking errors, when the oct-files were created.  But using "gcc (SUSE
Linux) 4.8.5" works for me.  The first issue "make check" detected is QT5
related:

 libinterp/octave-value/ov-class.cc-tst ......................ASAN:SIGSEGV
=================================================================
==4516== ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc
0x7fae70a6e2b4 sp 0x7faec2abf398 bp 0x7fae8aa78820 T10)
AddressSanitizer can not provide additional info.
    #0 0x7fae70a6e2b3 (+0x2b3)
Thread T10 (QThread) created by T0 here:
    #0 0x7faefcdf213b (/usr/lib64/libasan.so.0.0.0+0xb13b)
    #1 0x7faef8890fd5 (/usr/lib64/libQt5Core.so.5.6.2+0xaefd5)
==4516== ABORTING

Did I trapped into inappropriate threading options?

Best,
Kai.



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: Memory leaks in Octave

Rik-4
In reply to this post by Rik-4
On 09/15/2017 09:00 AM, [hidden email] wrote:
Subject:
Re: Memory leaks in Octave
From:
siko1056 [hidden email]
Date:
09/15/2017 05:55 AM
To:
[hidden email]
List-Post:
[hidden email]
Content-Transfer-Encoding:
quoted-printable
Precedence:
list
MIME-Version:
1.0
References:
<MTAwMDAxNi5ub21hZA.1505410361@quikprotect> [hidden email] <MTAwMDAxNy5ub21hZA.1505448073@quikprotect>
In-Reply-To:
<MTAwMDAxNy5ub21hZA.1505448073@quikprotect>
Message-ID:
[hidden email]
Content-Type:
text/plain; charset=UTF-8
Message:
3

Rik-4 wrote
Dmitri A. Sergatskov wrote
​My builds with gcc7.1.1 and ASAN pretty much fail 
I'm building with gcc-5.4.0 and I don't see this. 
My experience using "gcc-7 (SUSE Linux) 7.1.1 20170607" was also bad.  Lots
of linking errors, when the oct-files were created.  But using "gcc (SUSE
Linux) 4.8.5" works for me.  The first issue "make check" detected is QT5
related:

 libinterp/octave-value/ov-class.cc-tst ......................ASAN:SIGSEGV
=================================================================
==4516== ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc
0x7fae70a6e2b4 sp 0x7faec2abf398 bp 0x7fae8aa78820 T10)
AddressSanitizer can not provide additional info.
    #0 0x7fae70a6e2b3 (+0x2b3)
Thread T10 (QThread) created by T0 here:
    #0 0x7faefcdf213b (/usr/lib64/libasan.so.0.0.0+0xb13b)
    #1 0x7faef8890fd5 (/usr/lib64/libQt5Core.so.5.6.2+0xaefd5)
==4516== ABORTING

Did I trapped into inappropriate threading options?

Did you build with '-g'?  That is a really short backtrace that doesn't give much information about where the problem might lie.  The backtraces that I have been getting are more like a page long.  In fact, I have been building with '-ggdb3 -O0' so that as little optimization as possible that might remove intermediate variables of interest is performed.

--Rik
Reply | Threaded
Open this post in threaded view
|

Re: Memory leaks in Octave

Dmitri A. Sergatskov
​gcc 7.2.1 looks better​
​"​
stack-use-after-scope
​" are gone.
make check passes
.

interpreter execution time is much slower than a standard compile,
not sure if it is due to -O0 or asan.

Just fyi.


Dmitri.

--


Reply | Threaded
Open this post in threaded view
|

Re: Memory leaks in Octave

Dmitri A. Sergatskov
In reply to this post by siko1056


On Fri, Sep 15, 2017 at 7:55 AM, siko1056 <[hidden email]> wrote:
Rik-4 wrote
>
> Dmitri A. Sergatskov wrote
>> ​My builds with gcc7.1.1 and ASAN pretty much fail
> I'm building with gcc-5.4.0 and I don't see this.

My experience using "gcc-7 (SUSE Linux) 7.1.1 20170607" was also bad.  Lots
of linking errors, when the oct-files were created.  But using "gcc (SUSE
Linux) 4.8.5" works for me.  The first issue "make check" detected is QT5
related:

 libinterp/octave-value/ov-class.cc-tst ......................ASAN:SIGSEGV
=================================================================
==4516== ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc
0x7fae70a6e2b4 sp 0x7faec2abf398 bp 0x7fae8aa78820 T10)
AddressSanitizer can not provide additional info.
    #0 0x7fae70a6e2b3 (+0x2b3)
Thread T10 (QThread) created by T0 here:
    #0 0x7faefcdf213b (/usr/lib64/libasan.so.0.0.0+0xb13b)
    #1 0x7faef8890fd5 (/usr/lib64/libQt5Core.so.5.6.2+0xaefd5)
==4516== ABORTING

Did I trapped into inappropriate threading options?



​I recompiled with-qt and get  ​the same problem
(It passes when compiled without-qt without-fltk)


 
Best,
Kai.


​Dmitri.
--
Reply | Threaded
Open this post in threaded view
|

Re: Memory leaks in Octave

John W. Eaton
Administrator
In reply to this post by Rik-4
On 09/14/2017 01:32 PM, Rik 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.

Thanks for documenting this.

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

I noticed some direct leaks when just starting octave-cli and exiting
and fixed them with this change:

   http://hg.savannah.gnu.org/hgweb/octave/rev/a666e433aa21

Now I don't see any direct leaks when simply starting and exiting
octave-cli, but I do see large number of indirect leaks that look
something like

Indirect leak of 81472 byte(s) in 536 object(s) allocated from:
     #0 0x7fb36c0b6100 in operator new(unsigned long)
(/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdb100)
     #1 0x7fb36ab489a0 in
octave::symbol_table::symbol_record::symbol_record(octave::symbol_table::scope*,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&, octave_value const&, unsigned int)
/home/jwe/src/octave/libinterp/corefcn/symtab.h:625
     #2 0x7fb36b64d18b in
octave::symbol_table::scope::insert(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&, bool)
/home/jwe/src/octave/libinterp/corefcn/symtab.cc:1619
     #3 0x7fb36ab44f7d in octave::base_lexer::handle_identifier()
/home/jwe/src/octave/libinterp/parse-tree/lex.ll:3171


These appear to be caused by this changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/ef85638c605a

because it prevents symbol table scopes from being cleaned up properly
when a scope has a parent.  My goal with that patch was to avoid having
the parent scope disappear while it was still needed by the child
(nested or anonymous functions, for example).  It looks like I was a
little to good at that job and prevented them from ever being deleted.
Ooops.  I'm now looking at a way to fix this by using a different method
for caching the parent scope.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Memory leaks in Octave

Rik-4
In reply to this post by Rik-4
On 09/18/2017 09:00 AM, [hidden email] wrote:
> Subject: > Re: Memory leaks in Octave > From: > "Dmitri A. Sergatskov" [hidden email] > Date: > 09/17/2017 11:16 PM > To: > Rik [hidden email] > CC: > octave-maintainers [hidden email] > List-Post: > [hidden email] > Precedence: > list > MIME-Version: > 1.0 > References: > [hidden email] <MTAwMDAwOC5ub21hZA.1505494874@quikprotect> > In-Reply-To: > <MTAwMDAwOC5ub21hZA.1505494874@quikprotect> > Message-ID: > [hidden email] > Content-Type: > multipart/alternative; boundary="001a114020c2b53b1c055970aeea" > Message: > 1 > > ​gcc 7.2.1 looks better​ > ​"​ > stack-use-after-scope ​" are gone. > make check passes > . > > interpreter execution time is much slower than a standard compile, > not sure if it is due to -O0 or asan. > > Just fyi. >
Probably the -O0.  See below for execution times for "time make check".  Basically, 2X the execution time.

-O2
421.912u 29.084s 7:47.88 96.3%  0+0k 78256+106632io 313pf+0w

-g -O0
848.068u 31.464s 14:53.49 98.4% 0+0k 147398+98376io 608pf+0w

--Rik


Reply | Threaded
Open this post in threaded view
|

Re: Memory leaks in Octave

Rik-4
In reply to this post by Rik-4
On 09/18/2017 09:00 AM, [hidden email] wrote:
> Subject: > Re: Memory leaks in Octave > From: > "John W. Eaton" [hidden email] > Date: > 09/18/2017 07:45 AM > To: > [hidden email] > CC: > [hidden email] > List-Post: > [hidden email] > Content-Transfer-Encoding: > 7bit > Precedence: > list > MIME-Version: > 1.0 > References: > <MTAwMDAxNi5ub21hZA.1505410361@quikprotect> > In-Reply-To: > <MTAwMDAxNi5ub21hZA.1505410361@quikprotect> > Message-ID: > [hidden email] > Content-Type: > text/plain; charset=utf-8; format=flowed > Message: > 3 > > On 09/14/2017 01:32 PM, Rik 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. > > Thanks for documenting this. > >> 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. > > I noticed some direct leaks when just starting octave-cli and exiting and fixed them with this change: > > http://hg.savannah.gnu.org/hgweb/octave/rev/a666e433aa21 > > Now I don't see any direct leaks when simply starting and exiting octave-cli, but I do see large number of indirect leaks that look something like > > Indirect leak of 81472 byte(s) in 536 object(s) allocated from: > #0 0x7fb36c0b6100 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdb100) > #1 0x7fb36ab489a0 in octave::symbol_table::symbol_record::symbol_record(octave::symbol_table::scope*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, octave_value const&, unsigned int) /home/jwe/src/octave/libinterp/corefcn/symtab.h:625 > #2 0x7fb36b64d18b in octave::symbol_table::scope::insert(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool) /home/jwe/src/octave/libinterp/corefcn/symtab.cc:1619 > #3 0x7fb36ab44f7d in octave::base_lexer::handle_identifier() /home/jwe/src/octave/libinterp/parse-tree/lex.ll:3171 > > > These appear to be caused by this changeset: > > http://hg.savannah.gnu.org/hgweb/octave/rev/ef85638c605a > > because it prevents symbol table scopes from being cleaned up properly when a scope has a parent. My goal with that patch was to avoid having the parent scope disappear while it was still needed by the child (nested or anonymous functions, for example). It looks like I was a little to good at that job and prevented them from ever being deleted. Ooops. I'm now looking at a way to fix this by using a different method for caching the parent scope. > > jwe
I didn't see this because I usually run with ASAN_OPTIONS set to "leak_check_at_exit=0:verbose=1".  But, clearly this is a good reason to occasionally run the full Address Sanitizer which would detect slow memory leaks like this.

--Rik


Reply | Threaded
Open this post in threaded view
|

Re: Memory leaks in Octave

Rik-4
In reply to this post by Rik-4
On 09/18/2017 09:00 AM, [hidden email] wrote:
Subject:
Re: Memory leaks in Octave
From:
"Dmitri A. Sergatskov" [hidden email]
Date:
09/18/2017 05:34 AM
To:
siko1056 [hidden email]
CC:
octave-maintainers [hidden email]
List-Post:
[hidden email]
Precedence:
list
MIME-Version:
1.0
References:
<MTAwMDAxNi5ub21hZA.1505410361@quikprotect> [hidden email] <MTAwMDAxNy5ub21hZA.1505448073@quikprotect> [hidden email]
In-Reply-To:
[hidden email]
Message-ID:
[hidden email]
Content-Type:
multipart/alternative; boundary="94eb2c1c13a40efb89055975f53f"
Message:
2



On Fri, Sep 15, 2017 at 7:55 AM, siko1056 <[hidden email]> wrote:
Rik-4 wrote
>
> Dmitri A. Sergatskov wrote
>> ​My builds with gcc7.1.1 and ASAN pretty much fail
> I'm building with gcc-5.4.0 and I don't see this.

My experience using "gcc-7 (SUSE Linux) 7.1.1 20170607" was also bad.  Lots
of linking errors, when the oct-files were created.  But using "gcc (SUSE
Linux) 4.8.5" works for me.  The first issue "make check" detected is QT5
related:

 libinterp/octave-value/ov-class.cc-tst ......................ASAN:SIGSEGV
=================================================================
==4516== ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc
0x7fae70a6e2b4 sp 0x7faec2abf398 bp 0x7fae8aa78820 T10)
AddressSanitizer can not provide additional info.
    #0 0x7fae70a6e2b3 (+0x2b3)
Thread T10 (QThread) created by T0 here:
    #0 0x7faefcdf213b (/usr/lib64/libasan.so.0.0.0+0xb13b)
    #1 0x7faef8890fd5 (/usr/lib64/libQt5Core.so.5.6.2+0xaefd5)
==4516== ABORTING

Did I trapped into inappropriate threading options?



​I recompiled with-qt and get  ​the same problem
(It passes when compiled without-qt without-fltk)

I am now experiencing this too.  Since I wasn't getting this when I first explored using the Address Sanitizer, it implies that something has changed in just the last few weeks.  I will try and bisect.

--Rik
Reply | Threaded
Open this post in threaded view
|

Re: Memory leaks in Octave

Rik-4
In reply to this post by Rik-4
On 09/19/2017 10:22 AM, Rik wrote:
On 09/18/2017 09:00 AM, [hidden email] wrote:
Subject:
Re: Memory leaks in Octave
From:
"Dmitri A. Sergatskov" [hidden email]
Date:
09/18/2017 05:34 AM
To:
siko1056 [hidden email]
CC:
octave-maintainers [hidden email]
List-Post:
[hidden email]
Precedence:
list
MIME-Version:
1.0
References:
<MTAwMDAxNi5ub21hZA.1505410361@quikprotect> [hidden email] <MTAwMDAxNy5ub21hZA.1505448073@quikprotect> [hidden email]
In-Reply-To:
[hidden email]
Message-ID:
[hidden email]
Content-Type:
multipart/alternative; boundary="94eb2c1c13a40efb89055975f53f"
Message:
2



On Fri, Sep 15, 2017 at 7:55 AM, siko1056 <[hidden email]> wrote:
Rik-4 wrote
>
> Dmitri A. Sergatskov wrote
>> ​My builds with gcc7.1.1 and ASAN pretty much fail
> I'm building with gcc-5.4.0 and I don't see this.

My experience using "gcc-7 (SUSE Linux) 7.1.1 20170607" was also bad.  Lots
of linking errors, when the oct-files were created.  But using "gcc (SUSE
Linux) 4.8.5" works for me.  The first issue "make check" detected is QT5
related:

 libinterp/octave-value/ov-class.cc-tst ......................ASAN:SIGSEGV
=================================================================
==4516== ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc
0x7fae70a6e2b4 sp 0x7faec2abf398 bp 0x7fae8aa78820 T10)
AddressSanitizer can not provide additional info.
    #0 0x7fae70a6e2b3 (+0x2b3)
Thread T10 (QThread) created by T0 here:
    #0 0x7faefcdf213b (/usr/lib64/libasan.so.0.0.0+0xb13b)
    #1 0x7faef8890fd5 (/usr/lib64/libQt5Core.so.5.6.2+0xaefd5)
==4516== ABORTING

Did I trapped into inappropriate threading options?



​I recompiled with-qt and get  ​the same problem
(It passes when compiled without-qt without-fltk)

I am now experiencing this too.  Since I wasn't getting this when I first explored using the Address Sanitizer, it implies that something has changed in just the last few weeks.  I will try and bisect.


On my system configuring with --disable-java stops this from happening.  I didn't need to use --without-qt and --without-fltk.  If you can verify the same then a new bug report should be filed about that.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Memory leaks in Octave

Rik-4
In reply to this post by Rik-4
On 09/19/2017 11:07 AM, Rik wrote:
On 09/19/2017 10:22 AM, Rik wrote:
On 09/18/2017 09:00 AM, [hidden email] wrote:
Subject:
Re: Memory leaks in Octave
From:
"Dmitri A. Sergatskov" [hidden email]
Date:
09/18/2017 05:34 AM
To:
siko1056 [hidden email]
CC:
octave-maintainers [hidden email]
List-Post:
[hidden email]
Precedence:
list
MIME-Version:
1.0
References:
<MTAwMDAxNi5ub21hZA.1505410361@quikprotect> [hidden email] <MTAwMDAxNy5ub21hZA.1505448073@quikprotect> [hidden email]
In-Reply-To:
[hidden email]
Message-ID:
[hidden email]
Content-Type:
multipart/alternative; boundary="94eb2c1c13a40efb89055975f53f"
Message:
2



On Fri, Sep 15, 2017 at 7:55 AM, siko1056 <[hidden email]> wrote:
Rik-4 wrote
>
> Dmitri A. Sergatskov wrote
>> ​My builds with gcc7.1.1 and ASAN pretty much fail
> I'm building with gcc-5.4.0 and I don't see this.

My experience using "gcc-7 (SUSE Linux) 7.1.1 20170607" was also bad.  Lots
of linking errors, when the oct-files were created.  But using "gcc (SUSE
Linux) 4.8.5" works for me.  The first issue "make check" detected is QT5
related:

 libinterp/octave-value/ov-class.cc-tst ......................ASAN:SIGSEGV
=================================================================
==4516== ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc
0x7fae70a6e2b4 sp 0x7faec2abf398 bp 0x7fae8aa78820 T10)
AddressSanitizer can not provide additional info.
    #0 0x7fae70a6e2b3 (+0x2b3)
Thread T10 (QThread) created by T0 here:
    #0 0x7faefcdf213b (/usr/lib64/libasan.so.0.0.0+0xb13b)
    #1 0x7faef8890fd5 (/usr/lib64/libQt5Core.so.5.6.2+0xaefd5)
==4516== ABORTING

Did I trapped into inappropriate threading options?



​I recompiled with-qt and get  ​the same problem
(It passes when compiled without-qt without-fltk)

I am now experiencing this too.  Since I wasn't getting this when I first explored using the Address Sanitizer, it implies that something has changed in just the last few weeks.  I will try and bisect.


On my system configuring with --disable-java stops this from happening.  I didn't need to use --without-qt and --without-fltk.  If you can verify the same then a new bug report should be filed about that.

--Rik

Dmitri,

I filed a new bug report about Java and memory leaks (https://savannah.gnu.org/bugs/index.php?52061).  It turns out that any usage of the JVM seems to cause a segfault.

--Rik


Reply | Threaded
Open this post in threaded view
|

Re: Memory leaks in Octave

Dmitri A. Sergatskov


On Tue, Sep 19, 2017 at 1:36 PM, Rik <[hidden email]> wrote:

Dmitri,

I filed a new bug report about Java and memory leaks (https://savannah.gnu.org/bugs/index.php?52061).  It turns out that any usage of the JVM seems to cause a segfault.


​OK. Sorry my computer old and slow, it is still compiling.
Also, at least with gcc7.x the verbose keyword for asan is "verbosity=1".

 

--Rik



​Dmitri.
--

Reply | Threaded
Open this post in threaded view
|

Re: Memory leaks in Octave

Dmitri A. Sergatskov
​I also get a lot of alloc-dealloc-mismatch errors. Do we care about those?

Dmitri.
Reply | Threaded
Open this post in threaded view
|

Re: Memory leaks in Octave

John W. Eaton
Administrator
In reply to this post by Rik-4
On 09/19/2017 01:05 PM, Rik wrote:

> I didn't see this because I usually run with ASAN_OPTIONS set to
> "leak_check_at_exit=0:verbose=1".  But, clearly this is a good reason to
> occasionally run the full Address Sanitizer which would detect slow
> memory leaks like this.

With this changeset

   http://hg.savannah.gnu.org/hgweb/octave/rev/5bf2e2ceace2

I'm back down to 180k of indirect leaks and no direct leaks when
starting octave-cli and immediately exiting.  Most (or maybe all) appear
to be from classdef initialization, so I'll see if I can do something
about them as well.

jwe