Opened 10 years ago
Closed 10 years ago
#10833 closed defect (duplicate)
Unhandled SIGSEGV on large expand of iterated polynomial
Reported by: | katestange | Owned by: | AlexGhitza |
---|---|---|---|
Priority: | minor | Milestone: | sage-duplicate/invalid/wontfix |
Component: | algebra | Keywords: | expand, polynomial, polynomial ring |
Cc: | katestange, jpflori, burcin | Merged in: | |
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
Verified on 'Sage Version 4.6, Release Date: 2010-10-30' on my laptop and on nt.sagemath.org.
If I do this:
R.<x,c> = PolynomialRing(QQ,2) phi(x) = x^2 + c def iterkate(n): pol = x for i in range(1,n): pol = phi(pol) return pol g = expand(iterkate(7))
Then I get this on the last command:
------------------------------------------------------------ Unhandled SIGSEGV: A segmentation fault occurred in Sage. This probably occurred because a *compiled* component of Sage has a bug in it (typically accessing invalid memory) or is not properly wrapped with _sig_on, _sig_off. You might want to run Sage under gdb with 'sage -gdb' to debug this. Sage will now terminate (sorry). ------------------------------------------------------------
But if I do this
R.<x,c> = PolynomialRing(QQ,2) g = expand( (((((x^2 + c)^2 + c)^2 + c)^2 + c)^2 + c)^2 + c )
Then it is perfectly happy and g is a degree 64 polynomial (but in both cases it's the same polynomial I'm asking it to expand!). In the first example, it will crash if the "7" is anything above about 6. At 6, it is unreliable, and crashes sometimes. 5 and lower seems fine. I wasn't sure how to pare down to a more minimal example, given the circumstances.
It's entirely possible I'm doing something stupid here and interacting with sage in a bad way. If so, it's still a bug, but I'd love to know what I'm doing that sage doesn't like.
Anyway, here's some debug info:
Program received signal SIGSEGV, Segmentation fault. 0x03b3c3f5 in void std::__unguarded_linear_insert<__gnu_cxx::__normal_iterator<GiNaC::expair*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair, GiNaC::expair_rest_is_less>(__gnu_cxx::__normal_iterator<GiNaC::expair*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair, GiNaC::expair_rest_is_less) () from /usr/local/lib/sage-4.1.1-linux-Ubuntu_9.04-i686-Linux/local/lib/libpynac-0.2.so.1 Current language: auto The current source language is "auto; currently c++".
Change History (6)
comment:1 follow-up: ↓ 2 Changed 10 years ago by
- Cc jpflori burcin added
- Status changed from new to needs_info
comment:2 in reply to: ↑ 1 Changed 10 years ago by
comment:3 Changed 10 years ago by
On Fedora 14 x86_64 + Sage-4.6.2.rc1, I don't get any error with expand(iterkate(9))
. Running expand(iterkate(10))
eats up all of my 12 GB of ram but doesn't segfault.
comment:4 Changed 10 years ago by
On OS X 10.6.6, 4.6.2.rc0 under -gdb:
sage: g = expand(iterkate(6)) Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x0000000000000000 0x000000010789eb2e in GiNaC::mul::compare () (gdb) backtrace #0 0x000000010789eb2e in GiNaC::mul::compare () #1 0x00000001078079df in std::__unguarded_linear_insert<__gnu_cxx::__normal_iterator<GiNaC::expair*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair, GiNaC::expair_rest_is_less> () #2 0x000000010780a3b5 in std::__final_insertion_sort<__gnu_cxx::__normal_iterator<GiNaC::expair*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair_rest_is_less> () #3 0x0000000107804d1b in GiNaC::expairseq::canonicalize () #4 0x0000000107804d4c in GiNaC::expairseq::construct_from_epvector () #5 0x00000001077bf580 in GiNaC::add::add () #6 0x00000001077bf6d0 in GiNaC::add::expand () #7 0x00000001077fd165 in GiNaC::ex::expand () #8 0x0000000107deeb7f in __pyx_pf_4sage_8symbolic_10expression_10Expression_expand (__pyx_v_self=0x10c9cf170, __pyx_args=0x10023c050, __pyx_kwds=<value temporarily unavailable, due to optimizations>) at sage/symbolic/expression.cpp:13836 #9 0x00000001000b6472 in PyEval_EvalFrameEx () #10 0x00000001000b9002 in PyEval_EvalCodeEx () #11 0x00000001000b61b5 in PyEval_EvalFrameEx () #12 0x00000001000b9002 in PyEval_EvalCodeEx () #13 0x00000001000b875e in PyEval_EvalFrameEx () #14 0x00000001000b9002 in PyEval_EvalCodeEx () [etc]
comment:5 Changed 10 years ago by
I tested on sage 4.6.1 (debian in a vm) and got similar segfaults (SIGSEGV and SIGBUS, from 6).
Installing the fixed pynac from #9880 seems to fix the problem (tested till 9).
I put the patched spkg here (http://perso.telecom-paristech.fr/~flori/pynac-0.2.1-patched.spkg) if someone else wants to try it.
It ran until expand(iterkate(9)) on sage 4.6.2.rc0 (on debian, real machine, intel quad core smthg), with 10 it ate too much memory.
So I guess it is the same (kind of) problem as in #9880 (so it should be marked as duplicate).
The bug stated there "disappeared" with 4.6.1, that one seem to disappear with 4.6.2 but they are kind of random and other bug of this kind could still appear with new versions.
comment:6 Changed 10 years ago by
- Milestone changed from sage-4.6.2 to sage-duplicate/invalid/wontfix
- Resolution set to duplicate
- Status changed from needs_info to closed
This seems to be a duplicate of #9880. Please try with Sage-4.6.1 and let us know if the bug persists.