[Octave-bug-tracker] [bug #57033] Replace CXSPARSE with SPQR

[Markus Mützel]

Follow-up Comment #29, bug #57033 (project octave):

I tested the patch again by applying file #48691 on top of hg id
07c0df93ff9d.
In the meantime, I updated to Ubuntu 20.04.1 which packages suitesparse
5.7.1.
Running the following commands still crashes Octave:

a = [0, 2, 1; 2, 1, 2];
[q, r] = qr (a);
n = 20;  d = 0.2;
a = sprandn (n,n,d) + speye (n,n);
[c,r] = qr (a, ones (n,1));


Part of the "gdb" output is:

octave:1> a = [0, 2, 1; 2, 1, 2];
octave:2> [q, r] = qr (a);
octave:3> n = 20;  d = 0.2;
octave:4> a = sprandn (n,n,d) + speye (n,n);
octave:5> [c,r] = qr (a, ones (n,1));

Thread 6 "QThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe8a91700 (LWP 611210)]
__GI___libc_free (mem=0xffff00001fa0) at malloc.c:3102
3102    malloc.c: No such file or directory.
(gdb) bt
#0  __GI___libc_free (mem=0xffff00001fa0) at malloc.c:3102
#1  0x00007ffff2ba36b7 in SuiteSparse_free () at
/usr/lib/x86_64-linux-gnu/libsuitesparseconfig.so.5
#2  0x00007ffff2c6eb7d in cholmod_l_free () at
/usr/lib/x86_64-linux-gnu/libcholmod.so.3
#3  0x00007ffff2c6994b in cholmod_l_free_work () at
/usr/lib/x86_64-linux-gnu/libcholmod.so.3
#4  0x00007ffff5d7d21a in
octave::math::sparse_qr<SparseMatrix>::sparse_qr_rep::~sparse_qr_rep()
(this=0x7fffd8201290, __in_chrg=<optimized out>)
    at ../liboctave/numeric/sparse-qr.cc:346
#5  0x00007ffff5d88ef1 in octave::math::sparse_qr<SparseMatrix>::~sparse_qr()
(this=<optimized out>, __in_chrg=<optimized out>) at
../liboctave/numeric/sparse-qr.cc:2782
#6  octave::math::sparse_qr<SparseMatrix>::~sparse_qr() (this=<optimized out>,
__in_chrg=<optimized out>) at ../liboctave/numeric/sparse-qr.cc:2782
#7  0x00007ffff7708cdb in Fqr(octave_value_list const&, int) (args=...,
nargout=<optimized out>) at ../liboctave/array/MSparse.h:74
#8  0x00007ffff6fa277d in octave_builtin::execute(octave::tree_evaluator&,
int, octave_value_list const&) (this=0x7fffd80e2cf0, tw=..., nargout=2,
args=...)
    at ../libinterp/octave-value/ov-builtin.cc:59
#9  0x00007ffff7008c22 in octave_function::call(octave::tree_evaluator&, int,
octave_value_list const&) (this=0x7fffd80e2cf0, tw=..., nargout=2, args=...)
    at ../libinterp/octave-value/ov-fcn.cc:57
#10 0x00007ffff71e40fc in
octave::tree_index_expression::evaluate_n(octave::tree_evaluator&, int)
(this=0x7fffd81f1390, tw=..., nargout=2)
    at ../libinterp/parse-tree/pt-idx.cc:526
#11 0x00007ffff71b6609 in
octave::tree_multi_assignment::evaluate_n(octave::tree_evaluator&, int)
(this=0x7fffd8455440, tw=...) at ../libinterp/parse-tree/pt-assign.cc:201
#12 0x00007ffff71b90a0 in
octave::tree_multi_assignment::evaluate(octave::tree_evaluator&, int)
(this=<optimized out>, tw=..., nargout=<optimized out>)
    at ../libinterp/parse-tree/pt-assign.h:163


So nothing seems to have changed with the newer upstream packages.

Interestingly, I can't reproduce with a debug build configured with these
flags:

../configure CPPFLAGS=-I/usr/include/hdf5/serial
LDFLAGS="-L/usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/hdf5/serial"
--prefix=${HOME}/usr FFLAGS=-g CFLAGS=-g CXXFLAGS=-g


So could it be some compiler optimization is causing this? Any way to prevent
that?

@Simon: Are you able to reproduce in the meantime?

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?57033>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/