Heisenbug on Windows with current dev sources

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Heisenbug on Windows with current dev sources

John W. Eaton
Administrator
I built 2e364bd8efb5 for Windows using the mxe-octave configure options

   --enable-octave=default
   --enable-binary-packages
   --enable-devel-tools
   --enable-qt5
   --disable-system-opengl
   --enable-windows-64
   --enable-64

and Octave is exiting unexpectedly when executing __run_test_suite__.  I
tried running Octave under gdb and there is no failure.  Looking at the
fntests.log file, the last reported test is
...\fixed\publish\publish.tst.  All tests in that file pass if I cd to
the ...\fixed\publish directory and execute "test publish.tst".  The
next test should be ...\fixed\args.tst and I see no failures when
running tests for that file either.

Running on a Linux system with ASAN doesn't show any corrupted memory
issues.

Can anyone else building Octave for Windows duplicate the issue I see
with __run_test_suite__ exiting unexpectedly?  If so, do you see any
clues about what is happening?

Any ideas about how to debug this problem?

jwe



Reply | Threaded
Open this post in threaded view
|

Re: Heisenbug on Windows with current dev sources

PhilipNienhuis
John W. Eaton wrote

> I built 2e364bd8efb5 for Windows using the mxe-octave configure options
>
>    --enable-octave=default
>    --enable-binary-packages
>    --enable-devel-tools
>    --enable-qt5
>    --disable-system-opengl
>    --enable-windows-64
>    --enable-64
>
> and Octave is exiting unexpectedly when executing __run_test_suite__.  I
> tried running Octave under gdb and there is no failure.  Looking at the
> fntests.log file, the last reported test is
> ...\fixed\publish\publish.tst.  All tests in that file pass if I cd to
> the ...\fixed\publish directory and execute "test publish.tst".  The
> next test should be ...\fixed\args.tst and I see no failures when
> running tests for that file either.
>
> Running on a Linux system with ASAN doesn't show any corrupted memory
> issues.
>
> Can anyone else building Octave for Windows duplicate the issue I see
> with __run_test_suite__ exiting unexpectedly?  If so, do you see any
> clues about what is happening?
>
> Any ideas about how to debug this problem?

No idea, not even a clue, sorry, but since yesterday or so I see the same.
I configured with --ccache and --enable-fortran-in64 rather than
-enable-windows-64 (isn't the latter implied by --enable-64?), otherwise the
same as your options.

runtests ('/full/path/to/..../fixed/publish/') doesn't crash, nor do I get a
crash running all *.cc-tst files in tests/.../fixed/ manually - actually in
a for loop along the lines of

dirout = dir();
for ii=1:numel_dirout
  clear -g;
  test dirout(ii).name
endfor

JohnD once reported he could avoid a similar "Heisencrash" in
__run_test_suite__.m by running the fixed tests first.

Lately I see 2 FAILs in nest.tst and 4 earlier FAILs in a (AFAICS)
libinterp/ function. Could it be that the recent work in the parser affected
__run_test_suite__.m's functionality?
See here:
:
fixed\fcn-handle\static-method.tst ............................. PASS    4/4
..n-handle-derived-resolution\fcn-handle-derived-resolution.tst  PASS    3/7
                                                                   FAIL    4
fixed\local-functions\local_functions.tst ...................... PASS    1/1
fixed\nest\nest.tst ............................................ PASS  
20/23
                                                                   FAIL    2
                                                              REGRESSION   1
:

The net.tst failures related to undefined variables nst* or so. relevant
part of fntests.log attached. fntests.log
<http://octave.1599824.n4.nabble.com/file/t248596/fntests.log>  

FWIW there were some more reports on __run_test_suite__.m's apparent
instability in the last year but sooner or later it all got fixed somehow.

Philip




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

Reply | Threaded
Open this post in threaded view
|

Re: Heisenbug on Windows with current dev sources

John W. Eaton
Administrator
On 4/12/19 2:48 PM, PhilipNienhuis wrote:
> John W. Eaton wrote

>> Any ideas about how to debug this problem?
>
> No idea, not even a clue, sorry, but since yesterday or so I see the same.
> I configured with --ccache and --enable-fortran-in64 rather than
> -enable-windows-64 (isn't the latter implied by --enable-64?), otherwise the
> same as your options.
>
> runtests ('/full/path/to/..../fixed/publish/') doesn't crash, nor do I get a
> crash running all *.cc-tst files in tests/.../fixed/ manually - actually in
> a for loop along the lines of
>
> dirout = dir();
> for ii=1:numel_dirout
>    clear -g;
>    test dirout(ii).name
> endfor
>
> JohnD once reported he could avoid a similar "Heisencrash" in
> __run_test_suite__.m by running the fixed tests first.

Yeah, so I'm thinking that there is a bug somewhere, but triggering it
is not simple and it may be specific to some system-dependent code that
is only enabled on Windows.

> Lately I see 2 FAILs in nest.tst and 4 earlier FAILs in a (AFAICS)
> libinterp/ function. Could it be that the recent work in the parser affected
> __run_test_suite__.m's functionality?
> See here:
> :
> fixed\fcn-handle\static-method.tst ............................. PASS    4/4
> ..n-handle-derived-resolution\fcn-handle-derived-resolution.tst  PASS    3/7
>                                                                     FAIL    4
> fixed\local-functions\local_functions.tst ...................... PASS    1/1
> fixed\nest\nest.tst ............................................ PASS
> 20/23
>                                                                     FAIL    2
>                                                                REGRESSION   1

I think those are due to files omitted from the tar file distribution
and are fixed by the following change:

http://hg.savannah.gnu.org/hgweb/octave/rev/2e364bd8efb5

jwe