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

Tim Peters tim.one@home.com
Mon, 22 Jan 2001 04:18:04 -0500


[Martin]
> 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!).
=========================================================================
Running

    rt -x test_sax

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

    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
=========================================================================
Running

    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:
'dumps()\012
loads()\012
ok\012
loads() DATA\012
ok\012
dumps() binary\012
loads() binary\012
ok\012
loads() BINDATA\012
ok\012
dumps() RECURSIVE\012
ok\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/regrtest.py -r

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