test_sax fails on Windows under 3.4.0a2

[tim-one]

BPO	18992
Nosy	@tim-one, @loewis, @ned-deily, @serhiy-storchaka
Files	test_sax.out

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2013-09-10.19:07:48.691>
created_at = <Date 2013-09-10.01:02:25.870>
labels = ['tests']
title = 'test_sax fails on Windows under 3.4.0a2'
updated_at = <Date 2013-09-10.20:14:12.238>
user = 'https://github.com/tim-one'

bugs.python.org fields:

activity = <Date 2013-09-10.20:14:12.238>
actor = 'tim.peters'
assignee = 'none'
closed = True
closed_date = <Date 2013-09-10.19:07:48.691>
closer = 'loewis'
components = ['Tests']
creation = <Date 2013-09-10.01:02:25.870>
creator = 'tim.peters'
dependencies = []
files = ['31705']
hgrepos = []
issue_num = 18992
keywords = []
message_count = 9.0
messages = ['197415', '197416', '197431', '197432', '197454', '197458', '197459', '197462', '197466']
nosy_count = 4.0
nosy_names = ['tim.peters', 'loewis', 'ned.deily', 'serhiy.storchaka']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue18992'
versions = ['Python 3.4']

[tim-one]

Don't know whether this is new. Found it running the test suite under a 3.4.0a2 freshly installed from the python.org .msi installer:

== CPython 3.4.0a2 (v3.4.0a2:9265a2168e2c+, Sep 8 2013, 19:41:05) [MSC v.1600 32 bit (Intel)]
== Windows-Vista-6.0.6002-SP2 little-endian

regrtest -v test_sax output attached. Interestingly, test_sax passes under the tip HG Pythons I build myself.

Didn't we recently fix something like this??? Appears to be a line-end problem. Ya! Whoever builds the Windows installer needs to delete directory Lib\test\xmltestdata on their box, and then do "hg revert" on that directory to get fresh copies of the test data. .hgeol was changed to treat those files as binary, but Mercurial doesn't replace the files automatically just because .hgeol changed.

[ned-deily]

Martin builds the Windows installers.

[loewis]

Is there an easy way to recheck the entire tree, possibly reverting any files that don't match the content that they should have? I'd rather not throw the tree away.

[serhiy-storchaka]

hg update -C default

[tim-one]

Serhiy, did you test "hg update -C default"? Didn't work for me :-(

Martin, I don't know an easy way. eol fiddling in Hg seems brittle :-(

I suppose you could get a fresh clone and then _compare_ the checked-out files to your old clone. Then, from the old clone, delete the files that don't match. Then "hg revert -a" in the old clone. Then check again. If they all match, throw away the new clone. But, no, that's not really easy ;-)

[tim-one]

OK, "hg up -C" _can_ work, but it appears to require that "hg stat" shows that the files with the "bad" line endings are modified (M). That may or may not be the case, depending on lots of things.

Martin, can you verify that (for example) test.xml.out does have \r\n line ends in your tree? Maybe it doesn't, and the problem really lies elsewhere (unsure - some step in building the .msi, or maybe even the .msi changes line ends during installation - don't know).

I think bad line endings in the tree are most likely, though, since test_sax was failing in the same way for (at least) me and Terry Reddy when building our own Pythons on Windows, before changing .hgeol.

[tim-one]

BTW, the reason I wonder whether you don't have bad line ends in your tree is this: if you did, test_sax would have been failing for you too. I assume you run the test suite before building the installer ;-)

[loewis]

It turns out that TortoiseHg was showing the files as modified. I have now "reverted" my local changes, so this should be fine now. I was somewhat under time pressure when making the release, so I didn't notice then (and TortoiseHg seems to needs some time also to detect modifications and reversals).

And no, I don't run the test suite when making a release. If a test was failing, I would have to research what the problem is (or ignore the failure), which could easily delay the release by several days. I only verify that IDLE starts and the help file opens.

Thanks for your investigation.

[tim-one]

No problems, Martin - thanks for following up on this! :-)