[Top][All Lists]

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

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

From: Markus Mützel
Subject: [Octave-bug-tracker] [bug #57033] Replace CXSPARSE with SPQR
Date: Sat, 12 Sep 2020 05:55:09 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36 Edg/85.0.564.51

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

I tested the patch again by applying file #48691 on top of hg id
In the meantime, I updated to Ubuntu 20.04.1 which packages suitesparse
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
#2  0x00007ffff2c6eb7d in cholmod_l_free () at
#3  0x00007ffff2c6994b in cholmod_l_free_work () at
#4  0x00007ffff5d7d21a in
(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
#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,
    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

../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

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


Reply to this item at:


  Message sent via Savannah

reply via email to

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