Partial victory (was RE: [Python-Dev] RE: test_sax failing (Windows))

Tim Peters
Mon, 22 Jan 2001 04:18:04 -0500

> Well, it was atleast motivating enough to try it out on my Whistler
> installation. Purify would probably find this rather quickly; the code
> writes into the 257th element of a 256-elements array.

Ah!  You shouldn't do that <wink>.

> I've committed a fix.

But you should do that.  Thank you!

Here's where I am now:

All test_sax failures have gone away (yay!).

    rt -x test_sax

on Windows still blows up in test_extcall on the 2nd pass.  It does not blow

    using the debug build; or
    if test_sax is *not* excluded; or
    in the 1st pass; or
    when running text_extcall in isolation; or
    if the steps rt performs are done by hand

    rt -r

on Windows still sees test_cpickle fail in the first pass (with truncated
output), but succeed in the second pass.  First-pass failure is always like
so (modulo line breaks I'm inserting by hand):

test test_cpickle failed -- Tail of expected stdout unseen:
loads() DATA\012
dumps() binary\012
loads() binary\012
loads() BINDATA\012
dumps() RECURSIVE\012

I've also seen it fail at least once when doing the same thing by hand:

    del ..\lib\*.pyc
    del ..\lib\test\*.pyc
    python ../lib/test/ -r

else-i-would-have-asked-martin-to-look-for-a digit-to-change-in-<wink>-ly y'rs  - tim