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