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

[Mike Miller]

Update of bug #53330 (project octave):

                Severity:              3 - Normal => 4 - Important          
                  Status:                    None => Confirmed              
                 Summary: Hard crash when testing control pkg. => [octave
forge] (control) several functions crash Octave with SIGABRT from invalid free

    _______________________________________________________

Follow-up 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.


$
LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/blas:/usr/lib/x86_64-linux-gnu/lapack
OMP_NUM_THREADS=1 ./run-octave -cli -valgrind -W -q --eval 'pkg load control;
test h2syn'
...
==1907== Invalid write of size 4
==1907==    at 0xB26D08F: dgees_ (in
/usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1)
==1907==    by 0x1C660213: sb02rd_ (SB02RD.f:802)
==1907==    by 0x1C68DE52: sb10vd_ (SB10VD.f:332)
==1907==    by 0x1C67FD05: sb10hd_ (SB10HD.f:373)
==1907==    by 0x1C5D7F24: F__sl_sb10hd__(octave_value_list const&, int)
(sl_sb10hd.cc:120)
...
==1907==  Address 0x1b19153c is 0 bytes after a block of size 12 alloc'd
==1907==    at 0x4C2D91F: operator new[](unsigned long)
(vg_replace_malloc.c:423)
==1907==    by 0x1C5D7DA0: make_unique<bool []> (unique_ptr.h:831)
==1907==    by 0x1C5D7DA0: F__sl_sb10hd__(octave_value_list const&, int)
(sl_sb10hd.cc:113)
...
==1907== Invalid read of size 4
==1907==    at 0xB3B4C44: dtrsen_ (in
/usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1)
==1907==    by 0xB26D15A: dgees_ (in
/usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1)
==1907==    by 0x1C660213: sb02rd_ (SB02RD.f:802)
==1907==    by 0x1C68DE52: sb10vd_ (SB10VD.f:332)
==1907==    by 0x1C67FD05: sb10hd_ (SB10HD.f:373)
==1907==    by 0x1C5D7F24: F__sl_sb10hd__(octave_value_list const&, int)
(sl_sb10hd.cc:120)
...
==1907==  Address 0x1b19153c is 0 bytes after a block of size 12 alloc'd
==1907==    at 0x4C2D91F: operator new[](unsigned long)
(vg_replace_malloc.c:423)
==1907==    by 0x1C5D7DA0: make_unique<bool []> (unique_ptr.h:831)
==1907==    by 0x1C5D7DA0: F__sl_sb10hd__(octave_value_list const&, int)
(sl_sb10hd.cc:113)
...
valgrind: m_mallocfree.c:307 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi'
failed.
valgrind: Heap block lo/hi size mismatch: lo = 80, hi = 0.
This is probably caused by your program erroneously writing past the
end of a heap block and corrupting heap metadata.  If you fix any
invalid writes reported by Memcheck, this assertion failure will
probably go away.  Please try that before reporting this as a bug.
...


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.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?53330>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/