segfault with ASAN while running BIST tests for ov-class.cc

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

segfault with ASAN while running BIST tests for ov-class.cc

Rik-4
jwe,

This is repeatable for me.

run-octave -f
octave:1> test ov-class.cc
ASAN:SIGSEGV
=================================================================
==18433==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000
(pc 0x7f3d7e7942b4 bp 0x7f3d8ef5f2a0 sp 0x7ffde1363138 T0)
    #0 0x7f3d7e7942b3  (<unknown module>)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ??:0 ??
==18433==ABORTING

Probably due to recent changes in classdef.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: segfault with ASAN while running BIST tests for ov-class.cc

John W. Eaton
Administrator
On 04/27/2018 01:21 PM, Rik wrote:

> jwe,
>
> This is repeatable for me.
>
> run-octave -f
> octave:1> test ov-class.cc
> ASAN:SIGSEGV
> =================================================================
> ==18433==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000
> (pc 0x7f3d7e7942b4 bp 0x7f3d8ef5f2a0 sp 0x7ffde1363138 T0)
>      #0 0x7f3d7e7942b3  (<unknown module>)
>
> AddressSanitizer can not provide additional info.
> SUMMARY: AddressSanitizer: SEGV ??:0 ??
> ==18433==ABORTING
>
> Probably due to recent changes in classdef.

Hmm, ov-class.cc implements the old-style @DIR classes, so I'd be
surprised if my changes to classdef cause a problem there.  But possibly
it was my change to the evaluator?

Are you building the stable branch or default?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: segfault with ASAN while running BIST tests for ov-class.cc

John W. Eaton
Administrator
On 04/27/2018 03:16 PM, John W. Eaton wrote:

> On 04/27/2018 01:21 PM, Rik wrote:
>> jwe,
>>
>> This is repeatable for me.
>>
>> run-octave -f
>> octave:1> test ov-class.cc
>> ASAN:SIGSEGV
>> =================================================================
>> ==18433==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000
>> (pc 0x7f3d7e7942b4 bp 0x7f3d8ef5f2a0 sp 0x7ffde1363138 T0)
>>      #0 0x7f3d7e7942b3  (<unknown module>)
>>
>> AddressSanitizer can not provide additional info.
>> SUMMARY: AddressSanitizer: SEGV ??:0 ??
>> ==18433==ABORTING
>>
>> Probably due to recent changes in classdef.
>
> Hmm, ov-class.cc implements the old-style @DIR classes, so I'd be
> surprised if my changes to classdef cause a problem there.  But possibly
> it was my change to the evaluator?
>
> Are you building the stable branch or default?

I built the stable branch with

   .../configure --enable-address-sanitizer-flags --disable-java

I used --disable-java because I remember problems with asan and Java in
the past.  Testing ov-class.cc worked, but there was one test skipped
due to HAVE_JAVA being false.  Then I tried again with Java enabled and
I see what you see:

octave:2> test ov-class.cc
ASAN:DEADLYSIGNAL
=================================================================
==30937==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000
(pc 0x7fc0ee7c84f3 bp 0x7fc108874860 sp 0x7fc10aa01508 T9)
==30937==The signal is caused by a READ memory access.
==30937==Hint: address points to the zero page.
     #0 0x7fc0ee7c84f2  (<unknown module>)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (<unknown module>)
Thread T9 (QThread) created by T0 here:
     #0 0x7fc1411cf390 in __interceptor_pthread_create
(/usr/lib/x86_64-linux-gnu/libasan.so.4+0x37390)
     #1 0x7fc136a0b725 in QThread::start(QThread::Priority)
(/usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0xab725)

==30937==ABORTING

So I think this is our new favorite Java bug, not any change I made for
classdef or the interpreter.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: segfault with ASAN while running BIST tests for ov-class.cc

Rik-4
On 04/27/2018 01:06 PM, John W. Eaton wrote:

> On 04/27/2018 03:16 PM, John W. Eaton wrote:
>> On 04/27/2018 01:21 PM, Rik wrote:
>>> jwe,
>>>
>>> This is repeatable for me.
>>>
>>> run-octave -f
>>> octave:1> test ov-class.cc
>>> ASAN:SIGSEGV
>>> =================================================================
>>> ==18433==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000
>>> (pc 0x7f3d7e7942b4 bp 0x7f3d8ef5f2a0 sp 0x7ffde1363138 T0)
>>>      #0 0x7f3d7e7942b3  (<unknown module>)
>>>
>>> AddressSanitizer can not provide additional info.
>>> SUMMARY: AddressSanitizer: SEGV ??:0 ??
>>> ==18433==ABORTING
>>>
>>> Probably due to recent changes in classdef.
>>
>> Hmm, ov-class.cc implements the old-style @DIR classes, so I'd be
>> surprised if my changes to classdef cause a problem there.  But possibly
>> it was my change to the evaluator?
>>
>> Are you building the stable branch or default?
>
> I built the stable branch with
>
>   .../configure --enable-address-sanitizer-flags --disable-java
>
> I used --disable-java because I remember problems with asan and Java in
> the past.  Testing ov-class.cc worked, but there was one test skipped due
> to HAVE_JAVA being false.  Then I tried again with Java enabled and I see
> what you see:
>
> octave:2> test ov-class.cc
> ASAN:DEADLYSIGNAL
> =================================================================
> ==30937==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000
> (pc 0x7fc0ee7c84f3 bp 0x7fc108874860 sp 0x7fc10aa01508 T9)
> ==30937==The signal is caused by a READ memory access.
> ==30937==Hint: address points to the zero page.
>     #0 0x7fc0ee7c84f2  (<unknown module>)
>
> AddressSanitizer can not provide additional info.
> SUMMARY: AddressSanitizer: SEGV (<unknown module>)
> Thread T9 (QThread) created by T0 here:
>     #0 0x7fc1411cf390 in __interceptor_pthread_create
> (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x37390)
>     #1 0x7fc136a0b725 in QThread::start(QThread::Priority)
> (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0xab725)
>
> ==30937==ABORTING
>
> So I think this is our new favorite Java bug, not any change I made for
> classdef or the interpreter.

Yes, I came to the same conclusion and built with --disable-java and 'make
check' now passes.  *Sigh*.

--Rik