Bug? Segmentation while inverting a matrix
Hi, i'm getting a segmentation fault while inverting a matrix (the matrix itself is invertable, i checked with the symbolic package for octave). Can anyone give me some pointers why this is happening? Is the matrix ill-formed in some way or is this a bug? Many thanks in advance! I'm running archlinux (Kernel 4.14.12), my compiler is g++ 7.2.1, the GiNaC version i'm using is 1.7.2. Attached is a sample listing which produces the error (at least on my system). Greetings, Patrick
Hi, For the sake of consistency, I've copied your matrix in python sympy and got the following result for the inverse of A : Matrix([ [ gm/(gm/R2 + gm/R1), 0, 0, 0, -R1*(gm*(gm/R2 + gm/R1) - gm**2/R2)/(gm*(gm/R2 + gm/R1)), gm/(gm/R2 + gm/R1), 0, 0, -R1*(-gm*(gm/R2 + gm/R1)/R1 + gm**2/(R1*R2))/(gm*(gm/R2 + gm/R1))], [ 0, 0, 0, 0, 0, 0, 0, 0, 1], [ Ro*gm**2/(gm/R2 + gm/R1), 0, Ro, 0, R1*Ro*(-gm*(gm/R2 + gm/R1) + gm**2/R2)/(gm/R2 + gm/R1), Ro*gm**2/(gm/R2 + gm/R1), Ro, 0, -Ro*gm**2/(R2*(gm/R2 + gm/R1))], [-Rs*gm**2/(gm/R2 + gm/R1), 0, 0, Rs, -R1*Rs*(-gm**2*(gm/R2 + gm/R1) + gm**3/R2)/(gm*(gm/R2 + gm/R1)), -Rs*gm**2/(gm/R2 + gm/R1), 0, Rs, Rs*gm**2/(R2*(gm/R2 + gm/R1))], [ -gm/(R1*(gm/R2 + gm/R1)), 0, 0, 0, -gm/(R2*(gm/R2 + gm/R1)), -gm/(R1*(gm/R2 + gm/R1)), 0, 0, gm/(R1*R2*(gm/R2 + gm/R1))], [-gm/(R2*(-gm/R2 - gm/R1)), 0, 0, 0, gm/(R2*(-gm/R2 - gm/R1)), gm/(R1*(-gm/R2 - gm/R1)), 0, 0, -gm/(R1*R2*(-gm/R2 - gm/R1))], [ gm**2/(gm/R2 + gm/R1), 0, 1, 0, R1*(-gm*(gm/R2 + gm/R1) + gm**2/R2)/(gm/R2 + gm/R1), gm**2/(gm/R2 + gm/R1), 0, 0, -gm**2/(R2*(gm/R2 + gm/R1))], [ -gm**2/(gm/R2 + gm/R1), 0, 0, 1, -R1*(-gm**2*(gm/R2 + gm/R1) + gm**3/R2)/(gm*(gm/R2 + gm/R1)), -gm**2/(gm/R2 + gm/R1), 0, 0, gm**2/(R2*(gm/R2 + gm/R1))], [ gm/(R1*(gm/R2 + gm/R1)), 1, 0, 0, gm/(R2*(gm/R2 + gm/R1)), gm/(R1*(gm/R2 + gm/R1)), 0, 0, -gm/(R1*R2*(gm/R2 + gm/R1))]]) Seems to me there is a bug somewhere in GiNaC. jmt On Sun, 07 Jan 2018 17:08:18 +0100 Patrick Schulz <pschulz@posteo.de> wrote:
Hi,
i'm getting a segmentation fault while inverting a matrix (the matrix itself is invertable, i checked with the symbolic package for octave). Can anyone give me some pointers why this is happening? Is the matrix ill-formed in some way or is this a bug? Many thanks in advance!
I'm running archlinux (Kernel 4.14.12), my compiler is g++ 7.2.1, the GiNaC version i'm using is 1.7.2.
Attached is a sample listing which produces the error (at least on my system).
Greetings, Patrick
-- Jean-Marie Thomas http://www.dxdydz.net
On 01/07/2018 05:08 PM, Patrick Schulz wrote:
I'm running archlinux (Kernel 4.14.12), my compiler is g++ 7.2.1, the GiNaC version i'm using is 1.7.2.
For what it's worth, your example works fine on my system (with the same GiNaC and GCC versions). Maybe you could run the example from gdb, and get the backtrace to see where the error occurs?
On Mon, 8 Jan 2018 11:01:34 +0100, Vitaly Magerya <vmagerya@gmail.com> said:
VM> On 01/07/2018 05:08 PM, Patrick Schulz wrote: >> I'm running archlinux (Kernel 4.14.12), my compiler is g++ 7.2.1, >> the GiNaC version i'm using is 1.7.2. VM> For what it's worth, your example works fine on my system (with VM> the same GiNaC and GCC versions). It also works for me with GCC 7.2.0 and same GiNaC. -- Vladimir V. Kisil http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://goo.gl/EaG2Vu Software: Geometry of cycles http://moebinv.sourceforge.net/
Interesting! The segfault is generated in 0x00007ffff7a04bee in GiNaC::ex::subs(GiNaC::ex const&, unsigned int) const () from /usr/lib/libginac.so Backtrace: (gdb) bt #0 0x00007ffff7a04bee in GiNaC::ex::subs(GiNaC::ex const&, unsigned int) const () from /usr/lib/libginac.so.6 #1 0x00007ffff7ae9cb5 in GiNaC::gcd(GiNaC::ex const&, GiNaC::ex const&, GiNaC::ex*, GiNaC::ex*, bool, unsigned int) () from /usr/lib/libginac.so.6 #2 0x00007ffff7ae9427 in ?? () from /usr/lib/libginac.so.6 (and then a lot of #1 and #2 ...) #9033 0x00007ffff7af1502 in GiNaC::mul::normal(std::map<GiNaC::ex, GiNaC::ex, GiNaC::ex_is_less, std::allocator<std::pair<GiNaC::ex const, GiNaC::ex> > >&, std::map<GiNaC::ex, GiNaC::ex, GiNaC::ex_is_less, std::allocator<std::pair<GiNaC::ex const, GiNaC::ex> > >&) const () from /usr/lib/libginac.so.6 #9034 0x00007ffff7ae20f8 in GiNaC::ex::normal() const () from /usr/lib/libginac.so.6 #9035 0x00007ffff7ac5b89 in GiNaC::matrix::solve(GiNaC::matrix const&, GiNaC::matrix const&, unsigned int) const () from /usr/lib/libginac.so.6 #9036 0x00007ffff7ac6126 in GiNaC::matrix::inverse() const () from /usr/lib/libginac.so.6 #9037 0x0000555555557f1a in main () So main() -> matrix::inverse() -> matrix::solve() -> ex::normal() -> mul::normal() -> ??() -> GiNaC::gcd() Strange that it works with the same conditions... On Mon, 2018-01-08 at 13:30 +0000, Vladimir V. Kisil wrote:
On Mon, 8 Jan 2018 11:01:34 +0100, Vitaly Magerya <vmagerya@gmail.com> said:
VM> On 01/07/2018 05:08 PM, Patrick Schulz wrote: >> I'm running archlinux (Kernel 4.14.12), my compiler is g++ 7.2.1, >> the GiNaC version i'm using is 1.7.2.
VM> For what it's worth, your example works fine on my system (with VM> the same GiNaC and GCC versions).
It also works for me with GCC 7.2.0 and same GiNaC.
Sorry, i forgot the -g compiler switch. The segfault occurs during allocation: #0 0x00007ffff6d1c289 in malloc () from /usr/lib/libc.so.6 #1 0x00007ffff7641089 in operator new (sz=48) at /build/gcc/src/gcc/libstdc++-v3/libsupc++/new_op.cc:50 #2 0x00007ffff7b13983 in GiNaC::relational::duplicate() const () from /usr/lib/libginac.so.6 #3 0x00007ffff7a04109 in GiNaC::ex::construct_from_basic(GiNaC::basic const&) () from /usr/lib/libginac.so.6 #4 0x00007ffff79e25db in GiNaC::basic::eval() const () from /usr/lib/libginac.so.6 #5 0x00007ffff7a04129 in GiNaC::ex::construct_from_basic(GiNaC::basic const&) () from /usr/lib/libginac.so.6 The rest of the backtrace stays the same. Valgrind says it's a stackoverflow: ==16696== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==16696== Access not within mapped region at address 0x1FFE801F78 ==16696== Stack overflow in thread #1: can't grow stack to 0x1ffe801000 ==16696== at 0x6279F84: cln::gcd(cln::cl_I const&, cln::cl_I const&) (in /usr/lib/libcln.so.6.0.4) ==16696== If you believe this happened as a result of a stack ==16696== overflow in your program's main thread (unlikely but ==16696== possible), you can try to increase the size of the ==16696== main thread stack using the --main-stacksize= flag. ==16696== The main thread stack size used in this run was 8388608. ==16696== Stack overflow in thread #1: can't grow stack to 0x1ffe801000 I have 4 GB of RAM, so apparently not enough. Well, that also explains the huge backtrace. Since i want to solve a linear system (the inversion is just the reduction of the problem), i can use a different solve algorithm. This actually solves the segfault (at least for this problem). I attached a listing of the updated code. Thanks for the help, i'm open for any suggestions! Greetings! Patrick On Mon, 2018-01-08 at 20:17 +0100, Patrick Schulz wrote:
Interesting! The segfault is generated in
0x00007ffff7a04bee in GiNaC::ex::subs(GiNaC::ex const&, unsigned int) const () from /usr/lib/libginac.so
Backtrace:
(gdb) bt #0 0x00007ffff7a04bee in GiNaC::ex::subs(GiNaC::ex const&, unsigned int) const () from /usr/lib/libginac.so.6 #1 0x00007ffff7ae9cb5 in GiNaC::gcd(GiNaC::ex const&, GiNaC::ex const&, GiNaC::ex*, GiNaC::ex*, bool, unsigned int) () from /usr/lib/libginac.so.6 #2 0x00007ffff7ae9427 in ?? () from /usr/lib/libginac.so.6
(and then a lot of #1 and #2 ...)
#9033 0x00007ffff7af1502 in GiNaC::mul::normal(std::map<GiNaC::ex, GiNaC::ex, GiNaC::ex_is_less, std::allocator<std::pair<GiNaC::ex const, GiNaC::ex> > >&, std::map<GiNaC::ex, GiNaC::ex, GiNaC::ex_is_less, std::allocator<std::pair<GiNaC::ex const, GiNaC::ex> > >&) const () from /usr/lib/libginac.so.6 #9034 0x00007ffff7ae20f8 in GiNaC::ex::normal() const () from /usr/lib/libginac.so.6 #9035 0x00007ffff7ac5b89 in GiNaC::matrix::solve(GiNaC::matrix const&, GiNaC::matrix const&, unsigned int) const () from /usr/lib/libginac.so.6 #9036 0x00007ffff7ac6126 in GiNaC::matrix::inverse() const () from /usr/lib/libginac.so.6 #9037 0x0000555555557f1a in main ()
So main() -> matrix::inverse() -> matrix::solve() -> ex::normal() -> mul::normal() -> ??() -> GiNaC::gcd()
Strange that it works with the same conditions...
On Mon, 2018-01-08 at 13:30 +0000, Vladimir V. Kisil wrote:
> On Mon, 8 Jan 2018 11:01:34 +0100, Vitaly Magerya > <vmagerya@gmail.com> said:
VM> On 01/07/2018 05:08 PM, Patrick Schulz wrote: >> I'm running archlinux (Kernel 4.14.12), my compiler is g++ 7.2.1, >> the GiNaC version i'm using is 1.7.2.
VM> For what it's worth, your example works fine on my system (with VM> the same GiNaC and GCC versions).
It also works for me with GCC 7.2.0 and same GiNaC.
_______________________________________________ GiNaC-list mailing list GiNaC-list@ginac.de https://www.cebix.net/mailman/listinfo/ginac-list
participants (4)
-
jmt
-
Patrick Schulz
-
Vitaly Magerya
-
Vladimir V. Kisil