[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

__run_test_suite__ results in segfault on Windows systems

From: John W. Eaton
Subject: __run_test_suite__ results in segfault on Windows systems
Date: Tue, 15 Jan 2019 11:11:25 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1

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
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=...,
at /scratch/build/mxe-octave-w64-32-stable/tmp-stable-octave/octave-5.0.1/li
#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
#4  0x0000000000d7bd0f in F__go_figure__ (args=...)
at /scratch/build/mxe-octave-w64-32-stable/tmp-stable-octave/octave-5.0.1/li
#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
#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
#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
#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
#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
#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

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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]