__run_test_suite__ results in segfault on Windows systems

[John W. Eaton]

Can anyone else reproduce this problem?

Build and install a copy of Octave for Windows using recent stable 
sources and then execute __run_test_suite__ at the command prompt.  Does 
it crash Octave?  It does for me, and this is, I think relatively new 
behavior.

First, I noticed that the GUI disappeared while running the tests.

Next, I modified octave.vbs to run Octave with gdb.  That worked but 
didn't reveal much useful info because everything in the installer is 
stripped.

Then I replaced the liboctave, libinterp, and libgui DLLs with ones that 
are not stripped and tried again.  After running the tests again, I end 
up at the gdb prompt.  A stack trace shows the following:

Thread 21 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 680.0xad0]
0x00000000010490aa in graphics_toolkit::initialize (go=..., this=0x4fb36858)
    at 
/scratch/build/mxe-octave-w64-32-stable/tmp-stable-octave/octave-5.0.1/li
binterp/corefcn/graphics-toolkit.h:210
210 
/scratch/build/mxe-octave-w64-32-stable/tmp-stable-octave/octave-5.0.1/l
ibinterp/corefcn/graphics-toolkit.h: No such file or directory.
(gdb) where
#0  0x00000000010490aa in graphics_toolkit::initialize (go=...,
    this=0x4fb36858)
    at 
/scratch/build/mxe-octave-w64-32-stable/tmp-stable-octave/octave-5.0.1/li
binterp/corefcn/graphics-toolkit.h:210
#1  base_graphics_object::initialize (this=0x58a161f0, go=...)
    at libinterp/corefcn/graphics.h:2866
#2  0x0000000000ce4401 in graphics_object::initialize (this=0x4fb368d0)
    at libinterp/corefcn/graphics.h:3093
#3  xinitialize (h=...)
    at 
/scratch/build/mxe-octave-w64-32-stable/tmp-stable-octave/octave-5.0.1/li
binterp/corefcn/graphics.cc:3055
#4  0x0000000000d7bd0f in F__go_figure__ (args=...)
    at 
/scratch/build/mxe-octave-w64-32-stable/tmp-stable-octave/octave-5.0.1/li
binterp/corefcn/graphics.cc:12656
#5  0x0000000000a3856f in octave_builtin::call (this=0x50a7a2b0, tw=...,
    nargout=1, args=...)
    at 
/scratch/build/mxe-octave-w64-32-stable/tmp-stable-octave/octave-5.0.1/li
binterp/octave-value/ov-builtin.cc:65
#6  0x0000000000b47d0a in octave::tree_evaluator::visit_index_expression (
    this=0x4e59f4c8, idx_expr=...)
    at 
/scratch/build/mxe-octave-w64-32-stable/tmp-stable-octave/octave-5.0.1/li
binterp/parse-tree/pt-eval.cc:2008
#7  0x0000000001093146 in octave::tree_evaluator::evaluate (this=0x4e59f4c8,
    expr=0x4da888d0, nargout=<optimized out>)
--Type <RET> for more, q to quit, c to continue without paging--
    at 
/scratch/build/mxe-octave-w64-32-stable/tmp-stable-octave/octave-5.0.1/li
binterp/parse-tree/pt-eval.h:312
#8  0x0000000000b49332 in octave::tree_evaluator::visit_simple_assignment (
    this=0x4e59f4c8, expr=...)
    at 
/scratch/build/mxe-octave-w64-32-stable/tmp-stable-octave/octave-5.0.1/li
binterp/parse-tree/pt-eval.cc:2681
#9  0x0000000001093146 in octave::tree_evaluator::evaluate (this=0x4e59f4c8,
    expr=0x522f01a0, nargout=<optimized out>)
    at 
/scratch/build/mxe-octave-w64-32-stable/tmp-stable-octave/octave-5.0.1/li
binterp/parse-tree/pt-eval.h:312
#10 0x0000000000b44960 in octave::tree_evaluator::visit_statement (
    this=0x4e59f4c8, stmt=...)
    at 
/scratch/build/mxe-octave-w64-32-stable/tmp-stable-octave/octave-5.0.1/li
binterp/parse-tree/pt-eval.cc:2776

At the point of the crash, I see the following for the graphics_toolkit 
object:

(gdb) p *this
$1 = {rep = 0x4deac8e0}
(gdb) p *this.rep
$2 = {_vptr.base_graphics_toolkit = 0x6f9900d0, name = {
    static npos = 18446744073709551615,
    _M_dataplus = {<std::allocator<char>> = 
{<__gnu_cxx::new_allocator<char>> =
{<No data fields>}, <No data fields>}, _M_p = 0x4deac8f8 "qt"},
    _M_string_length = 2, {_M_local_buf = "qt\000º\rd-º\rd-º\rd-º",
      _M_allocated_capacity = 13451671603771372657}}, count = {count = 3}}

So I'm not sure why the crash is happening.  The toolkit object and rep 
pointer seem to be valid.  Maybe this is a threading problem?  In any 
case, I'm not sure how to debug it.

This failure happens when running the tests in the bug-55308.tst file. 
Unfortunately, it does not happen if I start Octave and run only this 
test.  It seems to be dependent on some other state that I'm currently 
only able to reproduce by running all the previous tests.  Needless to 
say, this is a slow process.

Since __run_test_suite__ worked without crashing for Octave 4.4.1, I 
suppose it will be possible to bisect, but that's likely to be quite a 
slow process.

Clearly, we need to have buildbot running the tests for Windows systems. 
 In the past, I've thought about doing that by having buildbot start a 
VM running Windows, the copy the installer to the VM, execute it to 
install Octave, and then execute the tests and return the log to the 
master buildbot.  But I haven't actually done this yet.  Does anyone 
have experience with doing something similar?

Comments?  Suggestions?

Thanks,

jwe