Segmentation fault in pynac when getting real/imag_part of a complex expression
Closed this issue · 17 comments
From this ask question the following crashes pynac with a stack overflow:
sage: n=var('n')
sage: assume(n, 'integer')
sage: (I^n).real_part()
/home/embray/src/sagemath/sage/local/lib/python2.7/site-packages/cysignals/signals.so(+0x80b5)[0x7f5b6da330b5]
/home/embray/src/sagemath/sage/local/lib/python2.7/site-packages/cysignals/signals.so(+0x8158)[0x7f5b6da33158]
/home/embray/src/sagemath/sage/local/lib/python2.7/site-packages/cysignals/signals.so(+0x96ad)[0x7f5b6da346ad]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f5b7cf14330]
/home/embray/src/sagemath/sage/local/lib/libpynac.so.18(_ZNK5GiNaC7numeric3gcdERKS0_+0x1d)[0x7f594bfdcd7d]
/home/embray/src/sagemath/sage/local/lib/libpynac.so.18(_ZN5GiNaC3gcdERKNS_7numericES2_+0x9)[0x7f594bfe0e29]
/home/embray/src/sagemath/sage/local/lib/libpynac.so.18(_ZNK5GiNaC3add15integer_contentEv+0xcc)[0x7f594bfcc80c]
/home/embray/src/sagemath/sage/local/lib/libpynac.so.18(_ZNK5GiNaC3add5powerERKNS_7numericE+0x37)[0x7f594bf09d97]
/home/embray/src/sagemath/sage/local/lib/libpynac.so.18(_ZNK5GiNaC5power4evalEi+0x1933)[0x7f594bff6cf3]
/home/embray/src/sagemath/sage/local/lib/libpynac.so.18(_ZN5GiNaC2ex20construct_from_basicERKNS_5basicE+0x76)[0x7f594bf283a6]
/home/embray/src/sagemath/sage/local/lib/libpynac.so.18(_ZNK5GiNaC3mul29combine_ex_with_coeff_to_pairERKNS_2exERKNS_7numericE+0xb8)[0x7f594bfbcfb8]
/home/embray/src/sagemath/sage/local/lib/libpynac.so.18(_ZNK5GiNaC9expairseq12evalchildrenEi+0xa7)[0x7f594bf31df7]
/home/embray/src/sagemath/sage/local/lib/libpynac.so.18(_ZNK5GiNaC3mul4evalEi+0x36)[0x7f594bfc2d16]
/home/embray/src/sagemath/sage/local/lib/libpynac.so.18(_ZN5GiNaC2ex20construct_from_basicERKNS_5basicE+0x76)[0x7f594bf283a6]
/home/embray/src/sagemath/sage/local/lib/libpynac.so.18(_ZNK5GiNaC3add20recombine_pair_to_exERKNS_6expairE+0x5d)[0x7f594bf050bd]
/home/embray/src/sagemath/sage/local/lib/libpynac.so.18(_ZNK5GiNaC3add4infoEj+0x196)[0x7f594bf05ae6]
/home/embray/src/sagemath/sage/local/lib/libpynac.so.18(_ZNK5GiNaC5power4evalEi+0x460)[0x7f594bff5820]
/home/embray/src/sagemath/sage/local/lib/libpynac.so.18(_ZN5GiNaC2ex20construct_from_basicERKNS_5basicE+0x76)[0x7f594bf283a6]
/home/embray/src/sagemath/sage/local/lib/libpynac.so.18(_ZNK5GiNaC5power4evalEi+0x12e5)[0x7f594bff66a5]
/home/embray/src/sagemath/sage/local/lib/libpynac.so.18(_ZN5GiNaC2ex20construct_from_basicERKNS_5basicE+0x76)[0x7f594bf283a6]
/home/embray/src/sagemath/sage/local/lib/libpynac.so.18(_ZNK5GiNaC5power9real_partEv+0x50f)[0x7f594bfef0af]
/home/embray/src/sagemath/sage/local/lib/libpynac.so.18(_ZNK5GiNaC5power9real_partEv+0x51)[0x7f594bfeebf1]
...
followed by an infinite recursion in GiNaC::power::real_part(). It doesn't crash without assume(n, 'integer'), and gives a correct answer:
sage: n=var('n')
sage: (I^n).real_part()
cos(1/2*pi*real_part(n))*e^(-1/2*pi*imag_part(n))
so stipulating that assume(n, 'integer') should set imag_part(n) == 0 and real_part(n) == n and give the correct answer...
CC: @rwst
Component: symbolics
Keywords: pynac assume
Author: Dave Morris
Branch/Commit: 248016b
Reviewer: Travis Scrimshaw
Issue created by migration from https://trac.sagemath.org/ticket/28357
Description changed:
---
+++
@@ -29,4 +29,12 @@
...
```
-followed by an infinite recursion in `GiNaC::power::real_part()`. It doesn't crash without `assume(n, 'integer')`.
+followed by an infinite recursion in `GiNaC::power::real_part()`. It doesn't crash without `assume(n, 'integer')`, and gives a correct answer:
+
+```
+sage: n=var('n')
+sage: (I^n).real_part()
+cos(1/2*pi*real_part(n))*e^(-1/2*pi*imag_part(n))
+```
+
+so stipulating that `assume(n, 'integer')` should set `imag_part(n) == 0` and `real_part(n) == n` and give the correct answer...Branch: public/28357
Diagnosis: Pynac's power::real_part method erroneously assumes that if n is a positive integer, then ((a + b*I)^n).expand() will multiply the factors to write the expression as a sum of monomials. But this is not true when n is symbolic, rather than being equal to a specific integer. Instead, the expression (a + b*I)^n is returned with no change, which leads to an infinite loop.
This pynac patch should fix the bug (for real_part and imag_part).
New commits:
cb80d0b | trac 28357 patch power::real_part |
1850eab | add doctests |
185acd9 | increment pynac version |
Commit: 185acd9
Author: Dave Morris
Merge conflict.
Changed branch from public/28357 to public/28357r1
Reviewer: Travis Scrimshaw
Thanks! This is now pynac PR 380.
STDOUT: CONFLICT (content): Merge conflict in build/pkgs/pynac/package-version.txt
Changed branch from public/28357r1 to public/28357r2
Rebased on #31694.
New commits:
e97c1b5 | update pynac to 0.7.28 |
3c131f7 | wip tarball |
11c80aa | updated tarball with PRs 377 and 378 |
c9c50e3 | build/pkgs/pynac: Upgrade to 0.7.29 |
31bbbc1 | Merge commit 'c9c50e3d1bb0a6d9ec17ede66a2f47da7cd89b01' of git://trac.sagemath.org/sage into 31694upgradepynac |
ec76ad9 | trac 28357 patch power::real_part |
dace50e | add doctests |
248016b | increment pynac version |
Changed branch from public/28357r2 to 248016b