On 5/25/07, Francesc Altet <faltet@carabos.com> wrote:
A Dijous 24 Maig 2007 20:33, Francesc Altet escrigué:

[SNIP]

Just for the record: I've found the culprit.  The problem here was the use of
the stride1 variable that was declared just above the main switch for opcodes
as:

intp stride1 = params.memsteps[arg1];

Unfortunately, this assignment gave problems because arg1 can take values out
of the range of memsteps array.  The solution was to use another variable,
that was initialized as:

intp sb1 = params.memsteps[arg1];

but in the VEC_ARG* macros, just after the BOUNDS_CHECK(arg1) call, so that it
checks that arg1 doesn't get out of range.  All in all, a very subtle bug
that would have evident for Numexpr main authors, but not for me. Anyway,
you can find the details of the fix in:
http://www.pytables.org/trac/changeset/2939

Don't feel bad, when I had a very similar problem early on when we were first adding multiple types and it mystified me for considerably longer than this seems to have stumped you.
 

I don't know exactly why, this wasn't giving problems with Linux boxes.
Fortunately, Windows platform is much more finicky in terms of memory
problems and brought this bug to my attention.  Oh, thanks god for letting
Windows be! ;)

;-)




--

//=][=\\

tim.hochberg@ieee.org