I created a Ticket on Sage's Trac: http://trac.sagemath.org/sage_trac/ticket/9880
It could be a problem with the comparison function "expair_rest_is_less" used by "std::sort" function like in the following link: http://gcc.gnu.org/ml/gcc-bugs/2010-08/msg01163.html The backtrace of our bug look similar: #0 GiNaC::power::compare (this=0x449be20, other=...) at power.cpp:899 #1 0x00007fffd7a9cc18 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 /home/jp/boulot/thèse/sage/sage-4.5.2/local/lib/ libpynac-0.2.so.0 #2 0x00007fffd7a9cefa in void std::__final_insertion_sort<__gnu_cxx::__normal_iterator<GiNaC::expair*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair_rest_is_less>(__gnu_cxx::__normal_iterator<GiNaC::expair*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, __gnu_cxx::__normal_iterator<GiNaC::expair*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair_rest_is_less) () from /home/jp/boulot/thèse/sage/ sage-4.5.2/local/lib/libpynac-0.2.so.0 #3 0x00007fffd7a95657 in sort<__gnu_cxx::__normal_iterator<GiNaC::expair*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair_rest_is_less> (this=<value optimized out>) at /usr/ include/c++/4.4/bits/stl_algo.h:5260 #4 GiNaC::expairseq::canonicalize (this=<value optimized out>) at expairseq.cpp:1177 #5 0x00007fffd7a994a4 in GiNaC::expairseq::construct_from_epvector (this=0x44a5070, v=<value optimized out>, do_index_renaming=<value optimized out>) at expairseq.cpp:1055 #6 0x00007fffd7a58685 in GiNaC::add::add (this=0x44a5070, vp=..., oc=<value optimized out>) at add.cpp:100 #7 0x00007fffd7a5871f in GiNaC::add::expand (this=0x449eb80, options=<value optimized out>) at add.cpp:669 #8 0x00007fffd7a9231d in GiNaC::ex::expand (this=<value optimized out>, options=3620337048) at ex.cpp:78 #9 0x00007fffd773e386 in __pyx_pf_4sage_8symbolic_10expression_10Expression_expand (__pyx_v_self=<value optimized out>, __pyx_args=0x601160, __pyx_kwds=0x0) at sage/symbolic/ expression.cpp:13604 #10 0x00007ffff7b107ca in call_function (f=0x44a4580, throwflag=<value optimized out>) at Python/ceval.c:3706 #11 PyEval_EvalFrameEx (f=0x44a4580, throwflag=<value optimized out>) at Python/ceval.c:2389 #12 0x00007ffff7b124ad in PyEval_EvalCodeEx (co=0x79c4c0, globals=<value optimized out>, locals=<value optimized out>, args=0x0, argcount=<value optimized out>, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2968 #13 0x00007ffff7b12582 in PyEval_EvalCode (co=0x449be20, globals=0x1135200007879, locals=0x7fffd7c9f598) at Python/ceval.c:522 #14 0x00007ffff7b3014c in run_mod ( . . . And valgrind output also: ==27910== Invalid read of size 8 ==27910== at 0x282C4BF1: 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) (ptr.h:99) ==27910== by 0x282C4EF9: void std::__final_insertion_sort<__gnu_cxx::__normal_iterator<GiNaC::expair*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair_rest_is_less>(__gnu_cxx::__normal_iterator<GiNaC::expair*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, __gnu_cxx::__normal_iterator<GiNaC::expair*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair_rest_is_less) (stl_algo.h:2161) ==27910== by 0x282BD656: GiNaC::expairseq::canonicalize() (stl_algo.h:5260) ==27910== by 0x282C14A3: GiNaC::expairseq::construct_from_epvector(std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > const&, bool) (expairseq.cpp:1055) ==27910== by 0x28280684: GiNaC::add::add(std::auto_ptr<std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::ex const&) (add.cpp:100) ==27910== by 0x2828071E: GiNaC::add::expand(unsigned int) const (add.cpp:669) ==27910== by 0x282BA31C: GiNaC::ex::expand(unsigned int) const (ex.cpp:78) ==27910== by 0x28811385: __pyx_pf_4sage_8symbolic_10expression_10Expression_expand(_object*, _object*, _object*) (expression.cpp:13604) ==27910== by 0x4F137C9: PyEval_EvalFrameEx (ceval.c:3706) ==27910== by 0x4F154AC: PyEval_EvalCodeEx (ceval.c:2968) ==27910== by 0x4F15581: PyEval_EvalCode (ceval.c:522) ==27910== by 0x4F3314B: PyRun_StringFlags (pythonrun.c:1335) ==27910== by 0x4F122DD: PyEval_EvalFrameEx (ceval.c:4437) ==27910== by 0x4F154AC: PyEval_EvalCodeEx (ceval.c:2968) ==27910== by 0x4E9BDDE: function_call (funcobject.c:524) ==27910== by 0x4E6FAA2: PyObject_Call (abstract.c:2492) ==27910== by 0xD7E0981: __pyx_pf_4sage_9structure_11sage_object_load (sage_object.c:7304) ==27910== by 0x4F137C9: PyEval_EvalFrameEx (ceval.c:3706) ==27910== by 0x4F154AC: PyEval_EvalCodeEx (ceval.c:2968) ==27910== by 0x4F15581: PyEval_EvalCode (ceval.c:522) ==27910== by 0x4F14853: PyEval_EvalFrameEx (ceval.c:4401) ==27910== by 0x4F154AC: PyEval_EvalCodeEx (ceval.c:2968) ==27910== by 0x4F13844: PyEval_EvalFrameEx (ceval.c:3802) ==27910== by 0x4F154AC: PyEval_EvalCodeEx (ceval.c:2968) ==27910== by 0x4F13844: PyEval_EvalFrameEx (ceval.c:3802) ==27910== Address 0x97e4280 is 16 bytes before a block of size 416 alloc'd ==27910== at 0x4C24CCC: operator new(unsigned long) (vg_replace_malloc.c:220) ==27910== by 0x28286727: std::vector<GiNaC::expair, std::allocator<GiNaC::expair> >::reserve(unsigned long) (new_allocator.h:89) ==27910== by 0x282C0D4A: GiNaC::expairseq::make_flat(std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > const&, bool) (expairseq.cpp:1138) ==27910== by 0x282C149B: GiNaC::expairseq::construct_from_epvector(std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > const&, bool) (expairseq.cpp:1051) ==27910== by 0x28280684: GiNaC::add::add(std::auto_ptr<std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::ex const&) (add.cpp:100) ==27910== by 0x2828071E: GiNaC::add::expand(unsigned int) const (add.cpp:669) ==27910== by 0x282BA31C: GiNaC::ex::expand(unsigned int) const (ex.cpp:78) ==27910== by 0x28811385: __pyx_pf_4sage_8symbolic_10expression_10Expression_expand(_object*, _object*, _object*) (expression.cpp:13604) ==27910== by 0x4F137C9: PyEval_EvalFrameEx (ceval.c:3706) ==27910== by 0x4F154AC: PyEval_EvalCodeEx (ceval.c:2968) ==27910== by 0x4F15581: PyEval_EvalCode (ceval.c:522) ==27910== by 0x4F3314B: PyRun_StringFlags (pythonrun.c:1335) ==27910== by 0x4F122DD: PyEval_EvalFrameEx (ceval.c:4437) ==27910== by 0x4F154AC: PyEval_EvalCodeEx (ceval.c:2968) ==27910== by 0x4E9BDDE: function_call (funcobject.c:524) ==27910== by 0x4E6FAA2: PyObject_Call (abstract.c:2492) ==27910== by 0xD7E0981: __pyx_pf_4sage_9structure_11sage_object_load (sage_object.c:7304) ==27910== by 0x4F137C9: PyEval_EvalFrameEx (ceval.c:3706) ==27910== by 0x4F154AC: PyEval_EvalCodeEx (ceval.c:2968) ==27910== by 0x4F15581: PyEval_EvalCode (ceval.c:522) ==27910== by 0x4F14853: PyEval_EvalFrameEx (ceval.c:4401) ==27910== by 0x4F154AC: PyEval_EvalCodeEx (ceval.c:2968) ==27910== by 0x4F13844: PyEval_EvalFrameEx (ceval.c:3802) ==27910== by 0x4F154AC: PyEval_EvalCodeEx (ceval.c:2968) ==27910== by 0x4F13844: PyEval_EvalFrameEx (ceval.c:3802) GiNaC documentation also mentions that this comparison function is not a "strict weak ordering" as required by "std::sort": "Note that this does not define a strict weak ordering since for any symbol x we have neither 3*x<2*x or 2*x<3*x. Handle with care!" but that function is made to be used that way so... Moreover replacing it by "expair_is_less" do not change anything. However, something fishy is going on here. On 8 sep, 10:04, Jean-Pierre Flori <jpfl...@gmail.com> wrote: > On 8 sep, 02:52, kcrisman <kcris...@gmail.com> wrote: > > > > > On Sep 7, 5:26 pm, Burcin Erocal <bur...@erocal.org> wrote: > > > > Hi, > > > > Here is a short example to replicate the first error mentioned below: > > > > b = [var('b_%s'%i) for i in range(4)] > > > > precomp = (2^b_2 + 2)*(2^b_1 + 2^(-b_1) + 2^b_1*2^b_0 - 2^b_1*2^(-b_0) > > > - 2^(-b_1)*2^b_0 - 2^(-b_1)*2^(-b_0) + 2^b_0 + 2^(-b_0) - 9) + (2^b_1 + > > > 2^(-b_1) + 2^b_1*2^b_0 - 2^b_1*2^(-b_0) - 2^(-b_1)*2^b_0 - > > > 2^(-b_1)*2^(-b_0) + 2^b_0 + 2^(-b_0) - 9)/2^b_2 > > > > repl_dict = {b_0: b_0, b_3: b_1, b_2: b_3, b_1: b_2} > > > P = precomp.substitute(repl_dict) > > > P.expand() > > > > I will take a break now. I'd appreciate any help tracking down the > > > problem (in pynac) if anybody has the time. > > Hi, > > Thanks a lot for producing a small piece of code reproducing the bug ! > I'll try to track something down from here with gdb. > > By the way, the above code doesn't *always* produce a bug (in fact it > didn't the first time I tried it...). > You can verify it by putting it in a "bug.sage" file and running the > following bash script: > > [...@napoleon sage-current]\$ cat bug.sh > #!/bin/bash > for (( i=1; i<$1; i++ )) > do > ./sage bug.sage &> /dev/null > if [ $? = 0 ] > then > echo $i > fi > done > > It gave the following output: > > [...@napoleon sage-current]\$ ./bug.sh 100 > 48 > 57 > 75 > 79 > 83 > > then: > > [...@napoleon sage-current]\$ ./bug.sh 100 > 4 > 6 > 7 > 26 > 28 > 68 > 69 > 99 > > So there must be something strange going on. > > > > > Did you open a ticket for this? > > I did not. > I took a look on the recent tickets in Trac, and also used the search > function for Pynac, but could not find anything relevant. > So I guess Burcin did not either. I'll do it today. > > > - kcrisman > > -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
