Opened 2 years ago
Closed 5 months ago
#28357 closed defect (fixed)
Segmentation fault in pynac when getting real/imag_part of a complex expression
Reported by:  embray  Owned by:  

Priority:  major  Milestone:  sage9.4 
Component:  symbolics  Keywords:  pynac assume 
Cc:  rws  Merged in:  
Authors:  Dave Morris  Reviewers:  Travis Scrimshaw 
Report Upstream:  N/A  Work issues:  
Branch:  248016b (Commits, GitHub, GitLab)  Commit:  248016bd236d7a45e162be16d17504255e2c9293 
Dependencies:  Stopgaps: 
Description (last modified by )
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/sitepackages/cysignals/signals.so(+0x80b5)[0x7f5b6da330b5] /home/embray/src/sagemath/sage/local/lib/python2.7/sitepackages/cysignals/signals.so(+0x8158)[0x7f5b6da33158] /home/embray/src/sagemath/sage/local/lib/python2.7/sitepackages/cysignals/signals.so(+0x96ad)[0x7f5b6da346ad] /lib/x86_64linuxgnu/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...
Change History (13)
comment:1 Changed 2 years ago by
 Description modified (diff)
comment:2 Changed 2 years ago by
 Cc rws added
comment:3 Changed 6 months ago by
 Branch set to public/28357
comment:4 Changed 6 months ago by
 Commit set to 185acd928e9308c5d0446e06ad0613a93a107482
 Milestone changed from sagewishlist to sage9.4
 Status changed from new to needs_review
comment:6 Changed 5 months ago by
 Branch changed from public/28357 to public/28357r1
comment:7 Changed 5 months ago by
 Commit changed from 185acd928e9308c5d0446e06ad0613a93a107482 to c629c306c1099d2c33c8266d6a42e89b71a54c3c
 Status changed from needs_work to needs_review
comment:8 Changed 5 months ago by
 Reviewers set to Travis Scrimshaw
 Status changed from needs_review to positive_review
LGTM.
Please also make a PR upstream: https://github.com/pynac/pynac.
comment:9 Changed 5 months ago by
Thanks! This is now pynac PR 380.
comment:10 Changed 5 months ago by
 Status changed from positive_review to needs_work
STDOUT: CONFLICT (content): Merge conflict in build/pkgs/pynac/packageversion.txt
comment:11 Changed 5 months ago by
 Branch changed from public/28357r1 to public/28357r2
comment:12 Changed 5 months ago by
 Commit changed from c629c306c1099d2c33c8266d6a42e89b71a54c3c to 248016bd236d7a45e162be16d17504255e2c9293
 Status changed from needs_work to positive_review
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

comment:13 Changed 5 months ago by
 Branch changed from public/28357r2 to 248016bd236d7a45e162be16d17504255e2c9293
 Resolution set to fixed
 Status changed from positive_review to closed
Note: See
TracTickets for help on using
tickets.
Diagnosis: Pynac's
power::real_part
method erroneously assumes that ifn
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 whenn
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
andimag_part
).New commits:
trac 28357 patch power::real_part
add doctests
increment pynac version