Opened 11 years ago

Closed 11 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:

Status badges

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: Changed 11 years ago by vbraun

  • Cc jpflori burcin added
  • Status changed from new to needs_info

This seems to be a duplicate of #9880. Please try with Sage-4.6.1 and let us know if the bug persists.

comment:2 in reply to: ↑ 1 Changed 11 years ago by dsm

Replying to vbraun:

This seems to be a duplicate of #9880. Please try with Sage-4.6.1 and let us know if the bug persists.

FWIW I see crashes on 4.6.1 and 4.6.2.rc0; I tried to apply the patches from #9880 but no luck.

comment:3 Changed 11 years ago by vbraun

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 11 years ago by dsm

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 11 years ago by jpflori

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 11 years ago by burcin

  • Milestone changed from sage-4.6.2 to sage-duplicate/invalid/wontfix
  • Resolution set to duplicate
  • Status changed from needs_info to closed

Thanks for tracking this Jean-Pierre. I'll do my best to review your patch in #9880 in the next few days and make a new pynac release.

I'm closing this as a duplicate of #9880.

Note: See TracTickets for help on using tickets.