- GiNaC-devel - ginac.de

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-233-gcbb93fa
by git＠ginac.de 09 Oct '10

09 Oct '10

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, master has been updated via cbb93fadabbd56ba006902967b15b2b2aebb037c (commit) from e99d0d58c1bbaa8ee73e4a90a90aa1086f2f813d (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit cbb93fadabbd56ba006902967b15b2b2aebb037c Author: Alexei Sheplyakov <alexei.sheplyakov(a)gmail.com> Date: Sat Oct 9 18:39:41 2010 +0200 mul: algebraic_subs_mul(), has(): don't write beyond the end of array algebraic_match_mul_with_mul() iterates over operands of mul, that is for (size_t i=0; i<e.nops(); ++i) However, the size of arrays (`vectors' in STL speak) passed to this function is seq.size(), which is nops() - 1 for any mul object. Thus algebraic_match_mul_with_mul() accesses beyond the arrays limit. Usually it's not a problem, since any reasonable implementation of std::vector<bool> packs booleans into ints (or longs). However, some STL implementations (in particular, the one shipped with msvc) are more picky, and access beyond the vector<bool> limits results in a segfault. Therefore let's play safe and allocate proper number of elements (that is, nops()) for those arrays (subsed and currsubsed). ----------------------------------------------------------------------- Summary of changes: ginac/mul.cpp | 12 +++++++----- 1 files changed, 7 insertions(+), 5 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

[SCM] GiNaC -- a C++ library for symbolic computations branch, ginac_1-5, updated. release_1-4-0-252-g052f124
by git＠ginac.de 09 Oct '10

09 Oct '10

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, ginac_1-5 has been updated via 052f124551d2b78104b0de2008db6b8819713625 (commit) from c40c54f17b68f79ee42833adb3364970385e2caa (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 052f124551d2b78104b0de2008db6b8819713625 Author: Alexei Sheplyakov <alexei.sheplyakov(a)gmail.com> Date: Sat Oct 9 18:39:41 2010 +0200 mul: algebraic_subs_mul(), has(): don't write beyond the end of array algebraic_match_mul_with_mul() iterates over operands of mul, that is for (size_t i=0; i<e.nops(); ++i) However, the size of arrays (`vectors' in STL speak) passed to this function is seq.size(), which is nops() - 1 for any mul object. Thus algebraic_match_mul_with_mul() accesses beyond the arrays limit. Usually it's not a problem, since any reasonable implementation of std::vector<bool> packs booleans into ints (or longs). However, some STL implementations (in particular, the one shipped with msvc) are more picky, and access beyond the vector<bool> limits results in a segfault. Therefore let's play safe and allocate proper number of elements (that is, nops()) for those arrays (subsed and currsubsed). (cherry picked from commit cbb93fadabbd56ba006902967b15b2b2aebb037c) ----------------------------------------------------------------------- Summary of changes: ginac/mul.cpp | 12 +++++++----- 1 files changed, 7 insertions(+), 5 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

[PATCH] mul: algebraic_subs_mul(), has(): don't write beyond the end of array
by Alexei Sheplyakov 09 Oct '10

09 Oct '10

algebraic_match_mul_with_mul() iterates over operands of mul, that is for (size_t i=0; i<e.nops(); ++i) However, the size of arrays (`vectors' in STL speak) passed to this function is seq.size(), which is nops() - 1 for any mul object. Thus algebraic_match_mul_with_mul() accesses beyond the arrays limit. Usually it's not a problem, since any reasonable implementation of std::vector<bool> packs booleans into ints (or longs). However, some STL implementations (in particular, the one shipped with msvc) are more picky, and access beyond the vector<bool> limits results in a segfault. Therefore let's play safe and allocate proper number of elements (that is, nops()) for those arrays (subsed and currsubsed). Thanks to Jan Rheinländer for a bug report. --- ginac/mul.cpp | 12 +++++++----- 1 files changed, 7 insertions(+), 5 deletions(-) diff --git a/ginac/mul.cpp b/ginac/mul.cpp index dfda410..3733bc4 100644 --- a/ginac/mul.cpp +++ b/ginac/mul.cpp @@ -729,6 +729,9 @@ bool algebraic_match_mul_with_mul(const mul &e, const ex &pat, exmap& repls, int factor, int &nummatches, const std::vector<bool> &subsed, std::vector<bool> &matched) { + GINAC_ASSERT(subsed.size() == e.nops()); + GINAC_ASSERT(matched.size() == e.nops()); + if (factor == (int)pat.nops()) return true; @@ -760,8 +763,8 @@ bool mul::has(const ex & pattern, unsigned options) const if(is_a<mul>(pattern)) { exmap repls; int nummatches = std::numeric_limits<int>::max(); - std::vector<bool> subsed(seq.size(), false); - std::vector<bool> matched(seq.size(), false); + std::vector<bool> subsed(nops(), false); + std::vector<bool> matched(nops(), false); if(algebraic_match_mul_with_mul(*this, pattern, repls, 0, nummatches, subsed, matched)) return true; @@ -771,8 +774,7 @@ bool mul::has(const ex & pattern, unsigned options) const ex mul::algebraic_subs_mul(const exmap & m, unsigned options) const { - std::vector<bool> subsed(seq.size(), false); - exvector subsresult(seq.size()); + std::vector<bool> subsed(nops(), false); ex divide_by = 1; ex multiply_by = 1; @@ -781,7 +783,7 @@ ex mul::algebraic_subs_mul(const exmap & m, unsigned options) const if (is_exactly_a<mul>(it->first)) { retry1: int nummatches = std::numeric_limits<int>::max(); - std::vector<bool> currsubsed(seq.size(), false); + std::vector<bool> currsubsed(nops(), false); exmap repls; if(!algebraic_match_mul_with_mul(*this, it->first, repls, 0, nummatches, subsed, currsubsed)) -- 1.7.1

1 0

Is this a bug?
by Jan private 08 Oct '10

08 Oct '10

Hello Alexei, while compiling an application with MSVC, I stumbled on this (because the code crashed) File: mul.cpp Function: ex mul::algebraic_subs_mul(const exmap & m, unsigned options) These two vectors are sized to seq.size(): std::vector<bool> subsed(seq.size(), false); std::vector<bool> currsubsed(seq.size(), false); They are then used in: algebraic_match_mul_with_mul() This iterates over the nops() of the mul: for (size_t i=0; i<e.nops(); ++i) { Can it be that the nops() of the mul is (always) equal to seq.size() + 1? Output of one example: ----- Code inserted in mul::algebraic_subs_mul(): std::cout << "mul::algebraic_subs_mul: nops: " << this->nops() << ", seq.size(): " << seq.size() << std::endl; std::cout << "mul::algebraic_subs_mul: " << tree << *this << dflt << std::endl; ------------ Output: mul::algebraic_subs_mul: nops: 2, seq.size(): 1 mul::algebraic_subs_mul: mul @00769848, hash=0x769820, flags=0x3, nops=2 mm 1 (numeric) @00753360, hash=0x160af41d, flags=0xf ----- overall_coeff 1/10 (numeric) @00769828, hash=0x36fbefb6, flags=0xf ===== ------------- Because the code crashes on the last iteration of the for loop, and if I size the vectors to seq.size()+1 (or maybe better nops()) it does not crash any more. Another possibility is that there is another error earlier on which results in a mul with seq.size() = 1 and nops() = 2 (for my example). Regards, Jan

2 1

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-232-ge99d0d5
by git＠ginac.de 04 Oct '10

04 Oct '10

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, master has been updated via e99d0d58c1bbaa8ee73e4a90a90aa1086f2f813d (commit) from 8fa654f2637fa755e890499ece1a7bc498779ea3 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit e99d0d58c1bbaa8ee73e4a90a90aa1086f2f813d Author: Alexei Sheplyakov <alexei.sheplyakov(a)gmail.com> Date: Mon Oct 4 09:21:05 2010 +0200 Avoid infinite loop when unarchiving realsymbol and possymbol. symbol::read_archive(): explicitly set status_flags::evaluated (and status_flags::expanded) on object being unarchived. These flags get reset by basic::operator=(const basic&) for realsymbol and possymbol, and nothing sets (except symbol ctor), so automatic evaluation never terminates (or rather, terminates due to a stack overflow). Therefore it's necessary need to set status_flags::evaluated explicitly. Thanks to Markus Fröb for a bugreport and a test case. ----------------------------------------------------------------------- Summary of changes: ginac/symbol.cpp | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

[SCM] GiNaC -- a C++ library for symbolic computations branch, ginac_1-5, updated. release_1-4-0-251-gc40c54f
by git＠ginac.de 04 Oct '10

04 Oct '10

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, ginac_1-5 has been updated via c40c54f17b68f79ee42833adb3364970385e2caa (commit) from 89d5356b4aa33cb4481575f9453f36c3404b015b (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit c40c54f17b68f79ee42833adb3364970385e2caa Author: Alexei Sheplyakov <alexei.sheplyakov(a)gmail.com> Date: Mon Oct 4 09:21:05 2010 +0200 Avoid infinite loop when unarchiving realsymbol and possymbol. symbol::read_archive(): explicitly set status_flags::evaluated (and status_flags::expanded) on object being unarchived. These flags get reset by basic::operator=(const basic&) for realsymbol and possymbol, and nothing sets (except symbol ctor), so automatic evaluation never terminates (or rather, terminates due to a stack overflow). Therefore it's necessary need to set status_flags::evaluated explicitly. Thanks to Markus Fröb for a bugreport and a test case. (cherry picked from commit e99d0d58c1bbaa8ee73e4a90a90aa1086f2f813d) ----------------------------------------------------------------------- Summary of changes: ginac/symbol.cpp | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

[PATCH] [bugfix] Avoid infinite loop when unarchiving realsymbol and possymbol.
by Alexei Sheplyakov 02 Oct '10

02 Oct '10

symbol::read_archive(): explicitly set status_flags::evaluated (and status_flags::expanded) on object being unarchived. These flags get reset by basic::operator=(const basic&) for realsymbol and possymbol, and nothing sets (except symbol ctor), so automatic evaluation never terminates (or rather, terminates due to a stack overflow). Therefore it's necessary need to set status_flags::evaluated explicitly. Thanks to Markus Fröb for a bugreport and a test case. --- ginac/symbol.cpp | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/ginac/symbol.cpp b/ginac/symbol.cpp index 9897bb4..8d05238 100644 --- a/ginac/symbol.cpp +++ b/ginac/symbol.cpp @@ -109,6 +109,15 @@ void symbol::read_archive(const archive_node &n, lst &sym_lst) for (lst::const_iterator it = sym_lst.begin(); it != sym_lst.end(); ++it) { if (is_a<symbol>(*it) && (ex_to<symbol>(*it).name == tmp_name)) { *this = ex_to<symbol>(*it); + // XXX: this method is responsible for reading realsymbol + // and possymbol objects too. But + // basic::operator=(const basic& other) + // resets status_flags::evaluated if other and *this are + // of different types. Usually this is a good idea, but + // doing this for symbols is wrong (for one, nothing is + // going to set status_flags::evaluated, evaluation will + // loop forever). Therefore we need to restore flags. + setflag(status_flags::evaluated | status_flags::expanded); return; } } -- 1.7.1

1 0

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-231-g8fa654f
by git＠ginac.de 30 Sep '10

30 Sep '10

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, master has been updated via 8fa654f2637fa755e890499ece1a7bc498779ea3 (commit) from e08cda1854bdb82f6706ec269233577690ae00e4 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 8fa654f2637fa755e890499ece1a7bc498779ea3 Author: Alexei Sheplyakov <varg(a)metalica.kh.ua> Date: Sat Aug 8 13:03:38 2009 +0300 ncmul::eval(): don't write beyond the end of the vector. ----------------------------------------------------------------------- Summary of changes: ginac/ncmul.cpp | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

Please apply patch 7a2ac488 to the master branch too
by Alexei Sheplyakov 30 Sep '10

30 Sep '10

Hello! Richard, Jens, could you please apply the patch 7a2ac488 ('ncmul::eval(): don't write beyond the end of vector') to the master branch? That patch fixes invalid code (which does work with GCC, but not with other compilers). Best regards, Alexei

1 0

Re: [GiNaC-devel] GiNaC msvc support patches
by Jan private 30 Sep '10

30 Sep '10

Hello Alexei, > > 6. make check compiles, but several of the executables crash. > > This is a bit strange. The only difference between master and 1.5 > is how parser handles functions (objects of type GiNaC::function). see attached patch. I _MSV_VER'ed it because it is pretty pointless. If something like this turns up every time there is a totally unrelated change, then I will get grey hairs pretty quickly :-( Anyway, with this patch all 58 tests pass successfully. > Could you please post the backtrace? How would I have done that (I guess it is unnecessary now)? Have you made any progress on the CLN patches? Best regards, Jan

1 0