bugGNU Octave - Bugs: bug #53330, [octave forge] (control) several...

 
 

bug #53330: [octave forge] (control) several functions crash Octave with SIGABRT from invalid free

Submitted by:  Doug Stewart <dastew>
Submitted on:  Mon 12 Mar 2018 08:34:02 PM UTC  
 
Category:  Octave Forge Package Severity:  4 - Important
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  doug Stewart Open/Closed:  Closed
Release:  dev Operating System:  Any

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)

Tue 20 Mar 2018 03:25:17 PM UTC, comment #10:

I'm surprised that it ever worked with OCTAVE_LOCAL_BUFFER (bool, ...) since the size of bool in C++ is typically 1 byte, but Fortran 77 requires that LOGICAL is the same size as INTEGER and REAL, which would typically be 4 bytes.

John W. Eaton <jwe>
Project Administrator
Tue 13 Mar 2018 08:49:41 PM UTC, comment #9:

Doug - try to remember post the URLs to the commits that fix an issue.

In this case

Mike Miller <mtmiller>
Project Administrator
Tue 13 Mar 2018 08:48:26 PM UTC, comment #8:

Looks good to me, closing.

Mike Miller <mtmiller>
Project Administrator
Tue 13 Mar 2018 08:17:47 PM UTC, comment #7:

This can be closed --- no more hard crashes.

This same bug might affect other packages.

Doug Stewart <dastew>
Tue 13 Mar 2018 06:35:05 PM UTC, comment #6:

Thank you Mike.
I will do the changes and report back.
give me a day or two.

Doug Stewart <dastew>
Tue 13 Mar 2018 06:25:32 PM UTC, comment #5:

For full exhibition, I debugged this by installing the libblas3-dbgsym and liblapack3-dbgsym packages from Debian, which add debug symbols for their internal functions. I also installed the lapack Debian source package so I could get exact line numbers.

I then ran Octave with valgrind again and got the exact LAPACK source file and line number where the invalid write took place (dgees.f:408). And it was obvious that it was trying to write into the LOGICAL BWORK array that was passed in.

Mike Miller <mtmiller>
Project Administrator
Tue 13 Mar 2018 06:21:49 PM UTC, comment #4:

The integers are not the problem. I see that jwe went though last year and fixed all of the integer references in the control package.

I think the remaining problem is the Fortran LOGICAL arrays called BWORK.

When I make the following changes to two of the SLICOT wrapper functions, the tests for h2syn now pass without crashing Octave.

I think there must be some optimization going on with the case of a C++ bool and the changes that were made to the OCTAVE_LOCAL_BUFFER macro. You must use the F77_LOGICAL type now for any Fortran LOGICAL arguments, return values, or in this case, scratch arrays, that are passed in to a Fortran routine.

Make that change to all of the SLICOT C++ wrapper routines and you should be ok.

Mike Miller <mtmiller>
Project Administrator
Tue 13 Mar 2018 12:46:48 PM UTC, comment #3:

One more thought.
Default is now 64 bit. The same make file is used to install control pkg. on stable and on default.

Are we sure that the .cc code and the fortran code is being compiled properly using the same make file for both stable and default?

Doug Stewart <dastew>
Tue 13 Mar 2018 01:13:21 AM UTC, comment #2:

@Mike
If you run the same test in stable it does not crash---- so if you stop at
the line that calls the fortran code and see what size the variables are in
the stable version , and do the same in default version, then you should
be able to see where the problem is.

This is what i would do if I knew how :-(
thanks for helping!

Doug

Doug Stewart <dastew>
Mon 12 Mar 2018 10:50:06 PM UTC, comment #1:

I'm retitling the bug report to update the description and make it easier to find.

I can confirm this error with control 3.1.0 on Octave's default branch. This does not affect Octave 4.2.1.

The error message indicates that libc's internal heap bookkeeping slots have been messed with. So gdb isn't going to be much help here, since it just reports the state of the program when the crash occurs, which is already too late.

The valgrind output is more helpful, but what's needed next is some reading of the code at the faulty module.

The following command shows the quoted Valgrind excerpts. I can provide the full Valgrind log if needed.

If I get a few minutes I will look into the "__sl_sb10hd__" routine, but you are probably right that this will end up being related to Octave's changes with respect to Fortran integer sizes.

If your code is using octave_idx_type to pass integers to Fortran, it may need to be updated to use the F77_INT type. And that may require Octave 4.2 or later, unless you want to try to make the code conditional to continue supporting older versions of Octave.

Mike Miller <mtmiller>
Project Administrator
Mon 12 Mar 2018 08:34:02 PM UTC, original submission:

This is different than a seg. fault. It does not say panic trying to save etc.

This is probably related to
http://lists.gnu.org/archive/html/octave-maintainers/2017-01/msg00011.html

This only happens with default and control-3.x.x
To see the first example install control pkg. and then run
test h2syn
or
test bstmodred

The crash occures at lin 141 in h2syn.m
It is a call to a .cc file which then calls a fortran subruotine.
[ak, bk, ck, dk, rcond] = _sl_sb10hd_ (a, b, c, d, ncon, nmeas);
The input variables are
a double 6x6
b double 6x5
c double 5x6
d double 5x5
ncon double 1x1 function
nmeas double 1x1 function

It also occures in line 281 of bstmodred. m
[ar, br, cr, dr, nr, hsv, ns] = _sl_ab09hd_ (a, b, c, d, dt, scaled, job, nr, ordsel, alpha, beta, ...
tol1, tol2);

It also crashes in hinfsyn.m at line 241
[ak, bk, ck, dk, rcond] = _sl_sb10fd_ (a, b, c, d, ncon, nmeas, gmax);

It also crashes in moen4.m at line 240
[sys, x0, info] = _slicot_identification_ ("moen4", nargout, varargin{:});

It also crashes in ncfsyn.m at line 383
[AK, BK, CK, DK, RCOND] = _sl_sb10id_ (A, B, C, D, FACTOR);

and at 296
[ak, bk, ck, dk, rcond] = _sl_sb10id_ (a, b, c, d, factor);

And probably more places. I stopped testing, and figured that if we fix these the rest might be fixed.

Any help would be appreciated.
If you tell me what needs changed I can do the rest.

Doug

Doug Stewart <dastew>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by dastew (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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-07-02 mtmiller Dependencies- => bugs #54221 is dependent
    2018-03-13 mtmiller StatusConfirmed => Fixed
        Open/ClosedOpen => Closed
    2018-03-12 mtmiller Severity3 - Normal => 4 - Important
        StatusNone => Confirmed
        SummaryHard crash when testing control pkg. => [octave forge] (control) several functions crash Octave with SIGABRT from invalid free

    Back to the top


    Powered by Savane 3.3