Administrator

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/mxeoctavew6432stable/tmpstableoctave/octave5.0.1/li
binterp/corefcn/graphicstoolkit.h:210
210
/scratch/build/mxeoctavew6432stable/tmpstableoctave/octave5.0.1/l
ibinterp/corefcn/graphicstoolkit.h: No such file or directory.
(gdb) where
#0 0x00000000010490aa in graphics_toolkit::initialize (go=...,
this=0x4fb36858)
at
/scratch/build/mxeoctavew6432stable/tmpstableoctave/octave5.0.1/li
binterp/corefcn/graphicstoolkit.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/mxeoctavew6432stable/tmpstableoctave/octave5.0.1/li
binterp/corefcn/graphics.cc:3055
#4 0x0000000000d7bd0f in F__go_figure__ (args=...)
at
/scratch/build/mxeoctavew6432stable/tmpstableoctave/octave5.0.1/li
binterp/corefcn/graphics.cc:12656
#5 0x0000000000a3856f in octave_builtin::call (this=0x50a7a2b0, tw=...,
nargout=1, args=...)
at
/scratch/build/mxeoctavew6432stable/tmpstableoctave/octave5.0.1/li
binterp/octavevalue/ovbuiltin.cc:65
#6 0x0000000000b47d0a in octave::tree_evaluator::visit_index_expression (
this=0x4e59f4c8, idx_expr=...)
at
/scratch/build/mxeoctavew6432stable/tmpstableoctave/octave5.0.1/li
binterp/parsetree/pteval.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/mxeoctavew6432stable/tmpstableoctave/octave5.0.1/li
binterp/parsetree/pteval.h:312
#8 0x0000000000b49332 in octave::tree_evaluator::visit_simple_assignment (
this=0x4e59f4c8, expr=...)
at
/scratch/build/mxeoctavew6432stable/tmpstableoctave/octave5.0.1/li
binterp/parsetree/pteval.cc:2681
#9 0x0000000001093146 in octave::tree_evaluator::evaluate (this=0x4e59f4c8,
expr=0x522f01a0, nargout=<optimized out>)
at
/scratch/build/mxeoctavew6432stable/tmpstableoctave/octave5.0.1/li
binterp/parsetree/pteval.h:312
#10 0x0000000000b44960 in octave::tree_evaluator::visit_statement (
this=0x4e59f4c8, stmt=...)
at
/scratch/build/mxeoctavew6432stable/tmpstableoctave/octave5.0.1/li
binterp/parsetree/pteval.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 bug55308.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
