Re: Octave 4.0.0 'make check' fails

[jmb]

On 05/31/2015 08:37 PM, Tatsuro MATSUOKA wrote:
> ----- Original Message -----
>
>> From: Tatsuro MATSUOKA 
>> To: jmb <jmb365
>> Cc: 
>> Date: 2015/6/1, Mon 07:57
>> Subject: Re: Octave 4.0.0 'make check' fails
>>
>> ----- Original Message -----
>>
>>>  From: jmb 
>>>  To: help-octave
>>>  Cc: 
>>>  Date: 2015/6/1, Mon 04:20
>>>  Subject: Octave 4.0.0 'make check' fails
>>>
>>>  Hello,
>>>
>>>  I just compiled octave 4.0.0 from sources in Ubuntu 12.04 (64bit) and
>>>  testing shows:
>>>
>>>  make check
>>>  Makefile:3060: warning: overriding commands for target `check'
>>>  .
>>>  . < several lines deleted for brevity >
>>>  .
>>>  Integrated test scripts:
>>>  liboctave/array/Array.cc-tst ....................... PASS     18/18
>>>  .
>>>  . < several lines deleted for brevity >
>>>  .
>>>  libinterp/dldfcn/__osmesa_print__.cc-tst ....................panic:
>>>  Segmentation fault -- stopping myself...
>>>
>>>  What should I check or redo?
>>>
>>>  -JMB
>>>
>>
>> Perhaps you have hit the well known issue.
>>
>> http://savannah.gnu.org/bugs/?44478
>>
>>
>> Start octave by
>> ./run-octave -g --no-gui
>> (Octave starts under the gdb(debugger))
>> Press enter some times until you see octave start up screen and execute
>>
>>>>  test __osmesa_print__.cc-tst
>> Perhaps octave crashes with Segmentation fault
>> From gdb prompt,
>> (gdb) bt
>> and see the back trace. What the back traces tell?
>>
>> Workaround
>>
>> $ export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libGL.so
>>
>>
>> may temporarily avoid the issue.
>>  
> Sorry for inadequate information.
>
>> ./run-octave -g --no-gui
>> (Octave starts under the gdb(debugger))
>
> (gdb) run
>
> and  press enter some times until you see octave start up screen and execute
>
> I have forgotten to mention "(gdb) run".
>
> Tatsuro
>

Hello,

Thank you for the fast response and the exact diagnosis and workaround. 
The gdb's backtrace pointed to:

>> test __osmesa_print__.cc-tst

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd2732700 (LWP 20413)]
0x00007ffff34f0569 in glGetIntegerv () from /usr/lib/nvidia-304/libGL.so.1
(gdb) bt
#0  0x00007ffff34f0569 in glGetIntegerv () from
/usr/lib/nvidia-304/libGL.so.1
#1  0x00007fffbf728792 in F__osmesa_print__ (args=...)
    at dldfcn/__osmesa_print__.cc:159
#2  0x00007ffff6e74418 in octave_builtin::do_multi_index_op (
    this=0x7fffc07351f0, nargout=0, args=..., lvalue_list=<optimized out>)
    at octave-value/ov-builtin.cc:131
#3  0x00007ffff6e732c3 in octave_builtin::subsref (this=0x7fffc07351f0,
    type=..., idx=..., nargout=0, lvalue_list=0x0)
    at octave-value/ov-builtin.cc:64
#4  0x00007ffff6e73c7c in octave_builtin::subsref (this=<optimized out>,
    type=..., idx=..., nargout=<optimized out>)
    at octave-value/ov-builtin.cc:46
#5  0x00007ffff6f595c8 in octave_value::subsref (this=<optimized out>,
    type=..., idx=..., nargout=<optimized out>) at octave-value/ov.cc:1302
#6  0x00007ffff6f59635 in octave_value::subsref (this=<optimized out>,
    type=..., idx=..., nargout=<optimized out>, lvalue_list=<optimized out>)
    at octave-value/ov.cc:1313

This output is very similar to the discussion thread you pointed me to.

The good news is the PRELOAD workaround works for me.  I can use that
until the problem is solved.  I will have to read that discussion thread
carefully to understand the cause.  In the meantime should I do anything
else to report/document the problem?  Or is it well known enough that I
should just wait?

Thank you very much again!

JMB