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

[Rik]

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