bugGNU Octave - Bugs: bug #59432, Octave exits with error code 3 for...

 
 

bug #59432: Octave exits with error code 3 for Bode plot

Submitted by:  Charles Praplan <charprap>
Submitted on:  Sun 08 Nov 2020 11:39:40 AM UTC  
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Need Info Assigned to:  None
Originator Name:  Charles Praplan Open/Closed:  Open
Release:  6.0.92 Operating System:  Microsoft Windows

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Mon 16 Nov 2020 06:57:28 PM UTC, comment #71: 

I cannot reproduce by running the script nor by pasting the commands.
I also don't see the random errors.

@jwe: It is difficult to say which virtual function is called because the compiler might have inlined some functions. But it might be `varval` in the `stack_frame` class which is defined pure virtual:

    virtual octave_value varval (const symbol_record& sym) const = 0;;

And it is called by `is_variable` in the same class which in turn is called in `is_variable` in the `tree_evaluator` class.

Markus Mützel <mmuetzel>
Project Member
Mon 16 Nov 2020 05:30:33 PM UTC, comment #70: 

I'm running from .m file.

Charles Praplan <charprap>
Mon 16 Nov 2020 04:39:54 PM UTC, comment #69: 

I forgot: I also see similar messages as you (random_errors.txt) and I can't force the abort or segfault on the command line interpreter. Only in the GUI.

Hg200 <hg200>
Mon 16 Nov 2020 04:22:35 PM UTC, comment #68: 

Are you running from .m file or do you paste the commands from clipboard? I am asking because of bug #59237. If i paste your commands (not on 6.0.92 but on the current default branch on linux) i also get SIGABRT. But if you run from .m file this can be also a different topic.

Hg200 <hg200>
Mon 16 Nov 2020 04:00:10 PM UTC, comment #67: 

This latest stack trace looks like there is an attempt to call a pure virtual function from the tree_evaluator::is_variable function.  But which one and how?

John W. Eaton <jwe>
Project Administrator
Mon 16 Nov 2020 03:53:19 PM UTC, comment #66: 

Sorry for asking for all these tests. But unfortunately, I'm unable to reproduce here.

It turns out the workspace model is updated independent of whether the widget is displayed or not. The code around where the crash might be triggered contains the following:
https://hg.savannah.gnu.org/hgweb/octave/file/a922c2176394/libgui/src/workspace-model.cc#l241

        // FIXME: fix size for objects, see kluge in ov.cc
        Matrix sz = val.size ();

Does anyone know if this could be related?

Markus Mützel <mmuetzel>
Project Member
Mon 16 Nov 2020 03:38:30 PM UTC, comment #65: 

Yes I could reproduce the crash with the "Workspace" widget closed.

Charles Praplan <charprap>
Mon 16 Nov 2020 03:29:28 PM UTC, comment #64: 

I don't know yet if I currently understand the backtrace. But it might have something to do with classdef objects(?) and how they are displayed in the workspace panel.

Can you test if you can still reproduce the crash when the "Workspace" widget is closed? That is the widget that displays the name, class, dimension, value of variables currently in scope.

Markus Mützel <mmuetzel>
Project Member
Mon 16 Nov 2020 03:23:45 PM UTC, comment #63: 

And I could not make the command line interpreter crash.

Charles Praplan <charprap>
Mon 16 Nov 2020 01:45:46 PM UTC, comment #62: 

Sorry for the missing version
... with version octave-2020-11-15-00-19-w64-64 ....

Charles Praplan <charprap>
Mon 16 Nov 2020 01:44:23 PM UTC, comment #61: 

The backtrace with version is appended (gdb_result3.txt). I let you interpret the differences...

(file #50284)

Charles Praplan <charprap>
Mon 16 Nov 2020 08:19:20 AM UTC, comment #60: 

Could you please repeat the steps from comment #47 and produce the full backtrace? Is it similar to the backtrace before jwe's fix or is it crashing at a different location now?

Markus Mützel <mmuetzel>
Project Member
Sun 15 Nov 2020 04:26:45 PM UTC, comment #59: 

Is there a difference if you use the command line interpreter (octave-cli) instead of the gui?

Hg200 <hg200>
Sun 15 Nov 2020 04:06:01 PM UTC, comment #58: 

1)
In fact the behavior is very special, as having a dynamic.

There are times where the crash does not occur.
In that case, a kind of random error message is sometimes displayed in the console (see appended file)

2)
When commenting out the legend function, I could not reproduce neither the crash nor the random messages (after a reasonable number of trials).

3)
Replacing the legend function with that of ver 5.2, I could not reproduce neither the crash nor the random messages (after a reasonable number of trials).

(file #50282)

Charles Praplan <charprap>
Sun 15 Nov 2020 10:44:46 AM UTC, comment #57: 

The 15th of November's w64 version did not build!!

So I tried version w64-64 instead (octave-2020-11-15-00-19-w64-64.7z).

Same crash!

Charles Praplan <charprap>
Sat 14 Nov 2020 09:59:31 AM UTC, comment #56: 

Full backtrace is appended in file gdb_result2.txt.

(file #50275)

Charles Praplan <charprap>
Sat 14 Nov 2020 09:16:21 AM UTC, comment #55: 

Sounds good to me.

@Charles: Since you seem to be the only one here that was able to trigger the issue, could you please re-run the failing code with a build from Kai's buildbots? The fix should be included in a build from the 15th of November or later:
https://buildbot.octave.space/#/download

Markus Mützel <mmuetzel>
Project Member
Sat 14 Nov 2020 02:03:30 AM UTC, comment #54: 

I pushed the following change on stable and merged with default:

http://hg.savannah.gnu.org/hgweb/octave/rev/336356206de7

John W. Eaton <jwe>
Project Administrator
Fri 13 Nov 2020 07:08:42 PM UTC, comment #53: 

Right, I guess we'll need to push the change and wait for a binary to be available for testing by someone who was able to trigger the crash.

The thing the patch attempts to avoid is having the stack pointer altered somehow between the time the unwind protect is set up and when it is executed (though I don't know how or where that is happening).

So instead of relying on the stack pointer position, we just grab a reference to the frame that is current when the function is executing and clear that directly instead of looking at the current stack frame at the time the unwind protect object is deleted.

I'll push a patch soon.  I'm also thinking about making the stack_frame::clear_values method not cause a panic if it is called.

John W. Eaton <jwe>
Project Administrator
Fri 13 Nov 2020 07:00:47 PM UTC, comment #52: 

Octave stable compiled successfully with this patch and all BISTs still pass afaict.
But I wasn't able to reproduce the crash in the first place. So I can't tell if it fixes it.

Markus Mützel <mmuetzel>
Project Member
Fri 13 Nov 2020 04:40:58 PM UTC, comment #51: 

I think the attached patch will avoid the crash.  I still don't understand why I am unable to duplicate the crash.

(file #50270)

John W. Eaton <jwe>
Project Administrator
Fri 13 Nov 2020 04:04:11 PM UTC, comment #50: 

Thank you for the test.
So the `abort` function is called indeed.
Could you please repeat that test and let gdb display the full backtrace (by continuing the pager with "c")?

Markus Mützel <mmuetzel>
Project Member
Fri 13 Nov 2020 03:10:35 PM UTC, comment #49: 

CPU: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz

Charles Praplan <charprap>
Fri 13 Nov 2020 02:11:35 PM UTC, comment #48: 

1)

>> version -blas

ans = OpenBLAS (config: OpenBLAS 0.3.10 NO_LAPACK NO_LAPACKE DYNAMIC_ARCH NO_AFFINITY Haswell MAX_THREADS=8)

>>


2) Breakpoint has been reached see appended file (gdb_result.txt)

(file #50268)

Charles Praplan <charprap>
Fri 13 Nov 2020 01:51:05 PM UTC, comment #47: 

Which CPU do you have?
What do you see for `version -blas`?

I'm not sure if `abort` is called from somewhere. So this could be a wild goose hunt. Anyway, could you try the following?:
- Start Octave and execute `__debug_octave__`.
- At the (gdb) prompt set a breakpoint in the `abort` function by executing `tb abort`. Continue execution of Octave with `c`.
- In Octave run the commands that cause the crash.
- Does gdb stop at the breakpoint? Which backtrace `bt` do you see from that point?

Markus Mützel <mmuetzel>
Project Member
Fri 13 Nov 2020 01:11:06 PM UTC, comment #46: 

Now I have installed Windows 10, version 20H2 (OS Build 19042.630).
The situation is the same.

Charles Praplan <charprap>
Wed 11 Nov 2020 11:45:44 AM UTC, comment #45: 

I have Windows 10, version 1909 (OS Build 18363.1139)

I have the portable version of Octave (octave-6.0.92-w64.7z), but as I mentioned in comment 12, I also tried with octave-2020-11-07-00-41-w64, with the same behavior.

I did not update the packages.

Charles Praplan <charprap>
Wed 11 Nov 2020 08:18:27 AM UTC, comment #44: 

@Charles: Which OS version are you using (Windows 7, Windows 8.1, Windows 10 20H2, ...)?
Is the control package you are using the one that came with Octave? Or did you re-install it?

Markus Mützel <mmuetzel>
Project Member
Tue 10 Nov 2020 10:53:10 PM UTC, comment #43: 

With a 6.0.93 nightly from nov 7 I can't reproduce it either.

Philip Nienhuis <philipnienhuis>
Project Member
Tue 10 Nov 2020 10:21:38 PM UTC, comment #42: 

So what to do next? I can't sustain the "confirmed" status now.

I could try again with a nightly from Kai's site, provided OF packages are built with it.

Philip Nienhuis <philipnienhuis>
Project Member
Tue 10 Nov 2020 10:18:05 PM UTC, comment #41: 

@JWE comment #36:
With 6.0.93 I cannot reproduce the crash anymore, nor with dev octave. At the end of the scripts I see a nice plot.

All I did in the mean time was reinstall the io package to the one on the OF website:
pkg install -verbose -global -forge io

Together with the error I saw (see comment #1; related to control package) it would make one believe I had an incomplete or borked octave_packages file affecting the control package; AFAIK that file is cooked up in mxe-octave these days.

I also had trouble with the 'pkg rebuild' command - it just wouldn't work on its own, only installing a package worked to create a fresh global octave_packages file. But I suppose that is anecdotical and maybe/probably a local issue.
FTR I have all my Octave installations in
C:\Programs\Octave\
rather than
C:\Program Files\GNU Octave\
(a.o., to avoid write permission issues when editing .m files in the global packages store.)

Philip Nienhuis <philipnienhuis>
Project Member
Tue 10 Nov 2020 07:38:03 PM UTC, comment #40: 

So it looks to me there is an issue with mat7 format and control data structures. If I use octave binary format instead I do not get warnings, but with mat7 I do.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 10 Nov 2020 03:40:12 PM UTC, comment #39: 

I have control-3.2.0 freshly re-compiled against the
octave b71672c8d337

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 10 Nov 2020 03:39:42 PM UTC, comment #38: 

>> ver

----------------------------------------------------------------------
GNU Octave Version: 6.0.92 (hg id: a2b4cd42a9cc)
GNU Octave License: GNU General Public License
Operating System: MINGW32_NT-6.2 Windows 6.2  x86_64
----------------------------------------------------------------------
Package Name         | Version | Installation directory
---------------------+---------+-----------------------
              audio  |   2.0.2 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\audio-2.0.2
     communications  |   1.2.2 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\communications-1.2.2
            control *|   3.2.0 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\control-3.2.0
     data-smoothing  |   1.3.0 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\data-smoothing-1.3.0
           database  |   2.4.4 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\database-2.4.4
          dataframe  |   1.2.0 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\dataframe-1.2.0
              dicom  |   0.4.0 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\dicom-0.4.0
          financial  |   0.5.3 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\financial-0.5.3
               fits  |   1.0.7 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\fits-1.0.7
fuzzy-logic-toolkit  |   0.4.5 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\fuzzy-logic-toolkit-0.4.5
                 ga  |  0.10.1 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\ga-0.10.1
            general  |   2.1.1 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\general-2.1.1
      generate_html  |   0.3.2 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\generate_html-0.3.2
           geometry  |   4.0.0 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\geometry-4.0.0
                gsl  |   2.1.1 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\gsl-2.1.1
              image  |  2.12.0 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\image-2.12.0
 instrument-control  |   0.5.0 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\instrument-control-0.5.0
           interval  |   3.2.0 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\interval-3.2.0
                 io  |   2.6.2 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\io-2.6.2
     linear-algebra  |   2.2.3 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\linear-algebra-2.2.3
               lssa  |   0.1.4 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\lssa-0.1.4
              ltfat  |   2.3.1 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\ltfat-2.3.1
            mapping  |   1.4.1 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\mapping-1.4.1
            matgeom  |   1.2.2 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\matgeom-1.2.2
      miscellaneous  |   1.3.0 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\miscellaneous-1.3.0
                nan  |   3.5.0 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\nan-3.5.0
             netcdf  |  1.0.14 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\netcdf-1.0.14
              nurbs  |  1.3.13 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\nurbs-1.3.13
                ocs  |   0.1.5 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\ocs-0.1.5
             odepkg  |   0.8.5 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\odepkg-0.8.5
              optim  |   1.6.0 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\optim-1.6.0
        optiminterp  |   0.3.6 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\optiminterp-0.3.6
         quaternion  |   2.4.0 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\quaternion-2.4.0
           queueing  |   1.2.7 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\queueing-1.2.7
             signal *|   1.4.1 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\signal-1.4.1
            sockets  |   1.2.0 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\sockets-1.2.0
          sparsersb  |   1.0.8 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\sparsersb-1.0.8
            splines  |   1.3.3 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\splines-1.3.3
         statistics  |   1.4.2 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\statistics-1.4.2
                stk  |   2.6.1 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\stk-2.6.1
            strings  |   1.2.0 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\strings-1.2.0
             struct  |  1.0.16 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\struct-1.0.16
           symbolic  |   2.9.0 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\symbolic-2.9.0
             tisean  |   0.2.3 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\tisean-0.2.3
                tsa  |   4.6.2 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\tsa-4.6.2
              video  |   2.0.0 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\video-2.0.0
            windows  |   1.5.0 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\windows-1.5.0
             zeromq  |   1.5.2 | C:\Programs\Octave\Octave-6.0.92\mingw64\share\octave\packages\zeromq-1.5.2

>>

Charles Praplan <charprap>
Tue 10 Nov 2020 03:05:55 PM UTC, comment #37: 

@Charles: Which OS version are you using? 64 or 32 bit?
Do you use the 64 bit or 32 bit version of Octave?

Markus Mützel <mmuetzel>
Project Member
Tue 10 Nov 2020 03:01:34 PM UTC, comment #36: 

Dmitri: Do you have the same version of the control package loaded?  If so, why would load warn about the object being converted to a struct?  I don't see how we can always guarantee that saved objects can be loaded by different versions if the internals have changed.

Charles: So it seems like there is some interaction with the control system package that is causing an error on some systems.  You and Philip seem to be able to trigger the bug but others have not.  Hmm.

John W. Eaton <jwe>
Project Administrator
Tue 10 Nov 2020 02:31:51 PM UTC, comment #35: 

Everything ok in that case (with and without control package loaded)!

Charles Praplan <charprap>
Tue 10 Nov 2020 02:30:09 PM UTC, comment #34: 

But "whos" should work in any case...

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 10 Nov 2020 01:51:32 PM UTC, comment #33: 

I meant to save the data that is actually used for the plot itself, not the control system objects that require the control package functions to be available in order to load them from a file.  To do that, it appears that you only need the values in the f, fs, MAG0 and MAG variables, not all the other objects in the workspace.

John W. Eaton <jwe>
Project Administrator
Tue 10 Nov 2020 01:24:26 PM UTC, comment #32: 

OK I see some funny stuff.
W/o control pkg:

octave -q -f
octave:1> load plot_crash_test_data.mat
warning: no constructor for class tfpoly
warning: load: element has been converted to a structure
warning: no constructor for class tfpoly
warning: load: element has been converted to a structure
warning: no constructor for class lti
warning: load: element has been converted to a structure
warning: no constructor for class tf
warning: load: element has been converted to a structure
warning: no constructor for class tfpoly
warning: load: element has been converted to a structure
warning: no constructor for class tfpoly
warning: load: element has been converted to a structure
warning: no constructor for class lti
warning: load: element has been converted to a structure
warning: no constructor for class tf
warning: load: element has been converted to a structure
octave:2> whos
Variables visible from the current scope:

variables in scope: top scope

   Attr Name           Size                     Bytes  Class
   ==== ====           ====                     =====  =====
        A              1x3                         24  double
        B              1x3                         24  double
        MAG         5000x1                      40000  double
        MAG0        5000x1                      40000  double
        PHASE       5000x1                      40000  double
        PHASE0      5000x1                      40000  double
        SYS_c          1x1                         42  struct
        SYS_d_zoh      1x1                         50  struct
        Ts             1x1                          8  double
        f              1x5000                   40000  double
        fc             1x1                          8  double
        fs             1x1                          8  double
        wc             1x1                          8  double

Total is 25012 elements using 200172 bytes

With control

 octave -q -f
octave:1> pkg load control
octave:2> load plot_crash_test_data.mat
warning: load: element has been converted to a structure
octave:3> whos
Variables visible from the current scope:

variables in scope: top scope

error: Invalid call to get.  Correct usage is:

-- Function File: get (SYS)
-- Function File: VALUE = get (SYS, "KEY")
-- Function File: [VAL1, VAL2, ...] = get (SYS, "KEY1", "KEY2", ...)
error: called from
    print_usage at line 98 column 5
    get at line 39 column 7
    subsref at line 53 column 9
    size at line 57 column 5
octave:4>

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 10 Nov 2020 12:59:03 PM UTC, comment #31: 

Here are the files...

(file #50235, file #50236)

Charles Praplan <charprap>
Tue 10 Nov 2020 12:47:41 PM UTC, comment #30: 

We need this data file and plot_crash_test_case_2.m

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 10 Nov 2020 12:07:22 PM UTC, comment #29: 

Here are the results of the testing I made, with the data saved in a file (matlab v7 format) and without calls to control package functions:

1) control package loaded

   => crash

  

2) control package NOT loaded

   => - no crash, plot is displayed correctly
      - but following warnings are displayed in console:

  

warning: no constructor for class tfpoly
warning: called from
    plot_crash_test_case_2 at line 5 column 1

warning: load: element has been converted to a structure
warning: called from
    plot_crash_test_case_2 at line 5 column 1

warning: no constructor for class tfpoly
warning: called from
    plot_crash_test_case_2 at line 5 column 1

warning: load: element has been converted to a structure
warning: called from
    plot_crash_test_case_2 at line 5 column 1

warning: no constructor for class lti
warning: called from
    plot_crash_test_case_2 at line 5 column 1

warning: load: element has been converted to a structure
warning: called from
    plot_crash_test_case_2 at line 5 column 1

warning: no constructor for class tf
warning: called from
    plot_crash_test_case_2 at line 5 column 1

warning: load: element has been converted to a structure
warning: called from
    plot_crash_test_case_2 at line 5 column 1

warning: no constructor for class tfpoly
warning: called from
    plot_crash_test_case_2 at line 5 column 1

warning: load: element has been converted to a structure
warning: called from
    plot_crash_test_case_2 at line 5 column 1

warning: no constructor for class tfpoly
warning: called from
    plot_crash_test_case_2 at line 5 column 1

warning: load: element has been converted to a structure
warning: called from
    plot_crash_test_case_2 at line 5 column 1

warning: no constructor for class lti
warning: called from
    plot_crash_test_case_2 at line 5 column 1

warning: load: element has been converted to a structure
warning: called from
    plot_crash_test_case_2 at line 5 column 1

warning: no constructor for class tf
warning: called from
    plot_crash_test_case_2 at line 5 column 1

warning: load: element has been converted to a structure
warning: called from
    plot_crash_test_case_2 at line 5 column 1

Charles Praplan <charprap>
Mon 09 Nov 2020 07:07:47 PM UTC, comment #28: 

Can the crash be reproduced without any external packages loaded?

Save the data from the example, and then in a fresh session, load it, use the same plot command and see whether it crashes.  If so, then we have at least narrowed the problem to something other than the control package.

John W. Eaton <jwe>
Project Administrator
Mon 09 Nov 2020 06:22:10 PM UTC, comment #27: 

Isn't the title misleading? From what is known so far, it is not bode () that is causing the issue but semilogx ().

Torsten Lilge <ttl>
Project Member
Mon 09 Nov 2020 05:09:43 PM UTC, comment #26: 

Thanks. That looks normal.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 09 Nov 2020 05:03:12 PM UTC, comment #25: 

Better wit 2 underscores :see appended file

(file #50234)

Charles Praplan <charprap>
Mon 09 Nov 2020 04:58:49 PM UTC, comment #24: 

OK -- it is not my typo it is a fance web formatting issues.


__opengl_info__

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 09 Nov 2020 04:57:04 PM UTC, comment #23: 

I guess it is my typo: There are two underscores in front and at the end.

_opengl_info_

Sorry about that.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 09 Nov 2020 04:47:47 PM UTC, comment #22: 

>> opengl_info

error: '_opengl_info_' undefined near line 1, column 1

Charles Praplan <charprap>
Mon 09 Nov 2020 04:39:59 PM UTC, comment #21: 

Charles: Could you post output of
_opengl_info_

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 09 Nov 2020 04:33:02 PM UTC, comment #20: 

Dmitri: It should be using the Mesa OpenGL library provided with Octave.  That should be configured to use llvmpipe.

John W. Eaton <jwe>
Project Administrator
Mon 09 Nov 2020 04:30:04 PM UTC, comment #19: 

I forgot how opengl is supposed to work on Win.
Does it use system library or the one (llvm-based) provided
by octave distribution?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 09 Nov 2020 04:30:03 PM UTC, comment #18: 

I installed the portable version.

Charles Praplan <charprap>
Mon 09 Nov 2020 04:20:22 PM UTC, comment #17: 

I'm unable to duplicate the problem on a Windows 10 system.  I installed from the w64 installer for 6.0.92 from alpha.gnu.org.

John W. Eaton <jwe>
Project Administrator
Mon 09 Nov 2020 02:56:32 PM UTC, comment #16: 

No crash when stepping through the Octave code !!!

Charles Praplan <charprap>
Mon 09 Nov 2020 02:49:05 PM UTC, comment #15: 

This doesn't look like a "normal crash". But for some reason Octave exits with error code 3.

Might be a red herring, but according to MSDN "abort" exits a program with error code 3 if no signal handler is set:
https://docs.microsoft.com/en-us/previous-versions/k089yyh0(v=vs.140)

Could you step through the Octave code to pinpoint which command causes Octave to exit unexpectedly?

Markus Mützel <mmuetzel>
Project Member
Mon 09 Nov 2020 02:48:19 PM UTC, comment #14: 

No I didn't observe any crash with gnuplot.

Charles Praplan <charprap>
Mon 09 Nov 2020 02:24:01 PM UTC, comment #13: 

Does it crash with gnuplot graphics (graphics_toolkit gnuplot)?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 09 Nov 2020 02:11:28 PM UTC, comment #12: 

I also tried version octave-2020-11-07-00-41-w64.
Same situation.

Charles Praplan <charprap>
Mon 09 Nov 2020 01:46:25 PM UTC, comment #11: 

Not sure that this is useful, bt produced no stack...

GNU gdb (GDB) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 9228
[New Thread 9228.0x2324]
[New Thread 9228.0xe90]
[New Thread 9228.0x3bdc]
[New Thread 9228.0x3f2c]
[New Thread 9228.0x4260]
[New Thread 9228.0x28d8]
[New Thread 9228.0x3e54]
[New Thread 9228.0x950]
[New Thread 9228.0x25a4]
[New Thread 9228.0x33a0]
[New Thread 9228.0x4200]
[New Thread 9228.0x29d4]
[New Thread 9228.0x3f28]
[New Thread 9228.0x3974]
[New Thread 9228.0x26c8]
[New Thread 9228.0x3fec]
[New Thread 9228.0x20f8]
[New Thread 9228.0x5d8]
[New Thread 9228.0x22f4]
[New Thread 9228.0x17f8]
[New Thread 9228.0x41a8]
[New Thread 9228.0x40c4]
[New Thread 9228.0x14f0]
[New Thread 9228.0x1ee4]
[New Thread 9228.0xdc4]
[New Thread 9228.0xa48]
[New Thread 9228.0x3f14]
[New Thread 9228.0xcc8]
[New Thread 9228.0x3dfc]
--Type <RET> for more, q to quit, c to continue without paging--c
Reading symbols from C:\Programs\Octave\OCTAVE~1.92\mingw64\bin\octave-gui.exe...
(No debugging symbols found in C:\Programs\Octave\OCTAVE~1.92\mingw64\bin\octave-gui.exe)
(gdb) c
Continuing.
[Thread 9228.0x3dfc exited with code 0]
[Thread 9228.0x20f8 exited with code 0]
[New Thread 9228.0x4394]
[New Thread 9228.0x1cec]
[New Thread 9228.0x3a90]
[New Thread 9228.0x39f8]
[New Thread 9228.0x12c8]
[New Thread 9228.0x35ac]
[New Thread 9228.0x135c]
[New Thread 9228.0x4358]
[New Thread 9228.0x292c]
[Thread 9228.0x33a0 exited with code 3]
[Thread 9228.0x3a90 exited with code 3]
[Thread 9228.0x39f8 exited with code 3]
[Thread 9228.0x1cec exited with code 3]
[Thread 9228.0x12c8 exited with code 3]
[Thread 9228.0x135c exited with code 3]
[Thread 9228.0x4358 exited with code 3]
[Thread 9228.0x292c exited with code 3]
[Thread 9228.0x4394 exited with code 3]
[Thread 9228.0xcc8 exited with code 3]
[Thread 9228.0x3f14 exited with code 3]
[Thread 9228.0xa48 exited with code 3]
[Thread 9228.0xdc4 exited with code 3]
[Thread 9228.0x1ee4 exited with code 3]
[Thread 9228.0x14f0 exited with code 3]
[Thread 9228.0x40c4 exited with code 3]
[Thread 9228.0x41a8 exited with code 3]
[Thread 9228.0x17f8 exited with code 3]
[Thread 9228.0x22f4 exited with code 3]
[Thread 9228.0x3fec exited with code 3]
[Thread 9228.0x3974 exited with code 3]
[Thread 9228.0x3f28 exited with code 3]
[Thread 9228.0x29d4 exited with code 3]
[Thread 9228.0x5d8 exited with code 3]
[Thread 9228.0x4200 exited with code 3]
[Thread 9228.0x25a4 exited with code 3]
[Thread 9228.0x950 exited with code 3]
[Thread 9228.0x3e54 exited with code 3]
[Thread 9228.0x28d8 exited with code 3]
[Thread 9228.0x4260 exited with code 3]
[Thread 9228.0x3f2c exited with code 3]
[Thread 9228.0x3bdc exited with code 3]
[Thread 9228.0xe90 exited with code 3]
[Thread 9228.0x26c8 exited with code 3]
[Thread 9228.0x35ac exited with code 3]
[Thread 9228.0x2324 exited with code 3]
--Type <RET> for more, q to quit, c to continue without paging--c
[Inferior 1 (process 9228) exited with code 03]
(gdb) bt
No stack.
(gdb)

Charles Praplan <charprap>
Mon 09 Nov 2020 01:20:53 PM UTC, comment #10: 

IIRC, there might be a prompt from the pager to continue with "c" when gdb is starting. This is not what I was referring to.
After you see the gdb prompt (a line starting with "(gdb)"), run the command `c`.

Markus Mützel <mmuetzel>
Project Member
Mon 09 Nov 2020 01:16:56 PM UTC, comment #9: 

Sorry I cannot return to Octave after having pressed c (and enter). Octave is frozen.
Access to octave is available only after quitting gdb.

Charles Praplan <charprap>
Mon 09 Nov 2020 12:34:55 PM UTC, comment #8: 

I cannot reproduce the crash here.

Could you please try to get a backtrace of the crash?
For this, start Octave and execute `__debug_octave__`. A command window with a gdb session that is attached to the Octave process will open.
In the gdb session, continue the Octave process by executing `c`.
Go back to Octave and execute the commands that cause the crash for you.
Return to the gdb session and have it display the backtrace with the command `bt`.

Please send the output from the gdb session.

Markus Mützel <mmuetzel>
Project Member
Mon 09 Nov 2020 10:52:25 AM UTC, comment #7: 

I had reference blas selected as default.
Switching to open blas does not change situation.

As already mentioned, I don't think that the c2d function is guilty. If I comment out the end of the script from line 19, everything is ok.

Charles Praplan <charprap>
Mon 09 Nov 2020 07:24:35 AM UTC, comment #6: 

Dmitri is probably referring to bug #59206.
That bug is already fixed in MXE Octave. But the fix is not yet part of any "official" release candidate.

@Charles Praplan: Could you test if the crash still occurs with a recent nightly build? You could download those from Kai's buildbots:
https://buildbot.octave.space/#/download

Markus Mützel <mmuetzel>
Project Member
Mon 09 Nov 2020 07:10:46 AM UTC, comment #5: 

The crash also occurs without "zoh" as parameter.

Charles Praplan <charprap>
Mon 09 Nov 2020 07:05:16 AM UTC, comment #4: 

I just wonder if we are hitting the same openblas bug.
Can you replace openblas with refrence blas and try to reproduce the crash.
I do not see any problem on linux with the latest stable
and control 3.2.0.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 09 Nov 2020 06:59:57 AM UTC, comment #3: 

If I comment out the end of the script from line 19, everything is ok. So I don't think that the c2d function is guilty!

Furthermore, everything works With octave 5.2.0.

And one remark, it's not an error which is reported, but a real crash of octave.

I have control 3.2.0.

Charles Praplan <charprap>
Sun 08 Nov 2020 09:46:28 PM UTC, comment #2: 

Thanks for the report and the testing. I am not sure which version of the control version is distributed with the mxe-build. Does the help of c2d contains the method "foh"?

And, does the error also occur when "zoh" (the default) is not given as parameter?

Torsten Lilge <ttl>
Project Member
Sun 08 Nov 2020 06:17:00 PM UTC, comment #1: 

Confirmed on 6.0.93 on Windows.
It's the line:

SYS_d_zoh = c2d(SYS_c,Ts,'zoh');

(3rd line in 4th stanza of OP's script) that provokes the crash.

In dev Octave I get an error two lines earlier in the uploaded script:

:
>> SYS_c = tf(B,A);
error: '__lti_input_idx__' undefined near line 211, column 211
error: called from
    tf at line 211 column 31
>>

perhaps a hint.

Philip Nienhuis <philipnienhuis>
Project Member
Sun 08 Nov 2020 11:39:40 AM UTC, original submission:  

Octave 6.0.92 crashes when executing appended script (plot_crash_test_case.m). This does not happen every time, but very often.

Charles Praplan <charprap>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #50284:  gdb_result3.txt added by charprap (7KiB - text/plain)
file #50282:  random_errors.txt added by charprap (1KiB - text/plain)
file #50275:  gdb_result2.txt added by charprap (6KiB - text/plain)
file #50270:  fcn-call-diff.txt added by jwe (2KiB - text/plain)
file #50268:  gdb_result.txt added by charprap (4KiB - text/plain)
file #50235:  plot_crash_test_case_2.m added by charprap (279B - application/octet-stream)
file #50236:  plot_crash_test_data.mat added by charprap (149KiB - application/octet-stream)
file #50234:  opengl_info.txt added by charprap (8KiB - text/plain)
file #50227:  plot_crash_test_case.m added by charprap (478B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by hg200 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by charprap (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 14 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-11-16 charprap Attached File- => Added gdb_result3.txt, #50284
    2020-11-16 mmuetzel StatusReady For Test => Need Info
    2020-11-15 charprap Attached File- => Added random_errors.txt, #50282
    2020-11-14 charprap Attached File- => Added gdb_result2.txt, #50275
    2020-11-14 jwe StatusNeed Info => Ready For Test
    2020-11-13 jwe Attached File- => Added fcn-call-diff.txt, #50270
    2020-11-13 charprap Attached File- => Added gdb_result.txt, #50268
    2020-11-13 mmuetzel StatusConfirmed => Need Info
    2020-11-10 charprap Attached File- => Added plot_crash_test_case_2.m, #50235
        Attached File- => Added plot_crash_test_data.mat, #50236
    2020-11-09 charprap Attached File- => Added opengl_info.txt, #50234
    2020-11-09 mmuetzel SummaryCrash => Octave exits with error code 3 for Bode plot
    2020-11-08 philipnienhuis StatusNone => Confirmed
    2020-11-08 charprap Attached File- => Added plot_crash_test_case.m, #50227

    Back to the top


    Powered by Savane 3.5