[GiNaC-list] Bug? Segmentation while inverting a matrix

Patrick Schulz pschulz at posteo.de
Tue Jan 9 07:52:49 CET 2018


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 at 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 at ginac.de
> https://www.cebix.net/mailman/listinfo/ginac-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: main.cpp
Type: text/x-c++src
Size: 1950 bytes
Desc: not available
URL: <http://www.cebix.net/pipermail/ginac-list/attachments/20180109/d070adf6/attachment.bin>


More information about the GiNaC-list mailing list