Summary: | testBug571055_* fail on Windows | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Andrey Loskutov <loskutov> |
Component: | Core | Assignee: | Stephan Herrmann <stephan.herrmann> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | manoj.palat, stephan.herrmann |
Version: | 4.19 | Keywords: | test |
Target Milestone: | 4.19 M3 | ||
Hardware: | PC | ||
OS: | Windows 10 | ||
See Also: |
https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/176350 https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=4ffde08df16264cfbff159024893e456a508cde8 |
||
Whiteboard: | |||
Bug Depends on: | |||
Bug Blocks: | 571055 |
Description
Andrey Loskutov
2021-02-15 03:29:56 EST
New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/176350 This was a freaky failure. We get totally entangled in three different possible reasons why strings might differ: (1) line ends should always be normalized (2) some magic is needed for matching the file path in the error message (3) error messages could substantially differ According to (1) line ends are not the problem. According to the message of the failed assert (2) didn't look like the problem, nor is (3) to blame. It turns out the left hand of the test infrastructure doesn't know what the right hand does: We did detect a difference in paths, but this difference doesn't show in the failure. What's more: the detected difference is only *created* by the test infrastructure, by normalizing the path in the actual stderr text by replacing the real location with the string "---OUTPUT_DIR_PLACEHOLDER---". (In reply to Eclipse Genie from comment #1) > New Gerrit change created: > https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/176350 Fixes two issues: * fix the actual test by using "---OUTPUT_DIR_PLACEHOLDER---" instead of the real path OUTPUT_DIR. * add assertions that detect bogus tests: output dir normalization should never have an effect on the *expected* out / err string. Since I don't have a Windows machine, the actual success can only be determined by the next integration build ... @Andrey, I'm a bit out of sync: on the one hand gerrit tells me, I should not submit this right now, but there used to be an exception for test-only changes anyway. Is this exception still in place? If not, does the "regression"-exception apply to this? Or should I really wait till after M3? (In reply to Stephan Herrmann from comment #3) > @Andrey, I'm a bit out of sync: on the one hand gerrit tells me, I should > not submit this right now, but there used to be an exception for test-only > changes anyway. Is this exception still in place? Sure, so once the gerrit will be green in actual JDT tests, we can merge. The gerrit warning is for committers that don't read/don't understand releng mails about freeze periods. Gerrit change https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/176350 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=4ffde08df16264cfbff159024893e456a508cde8 (In reply to Eclipse Genie from comment #5) > Gerrit change https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/176350 was > merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=4ffde08df16264cfbff159024893e456a508cde8 Released for 4.19 M3 Verified for Eclipse 4.19 M3 with test results at https://download.eclipse.org/eclipse/downloads/drops4/I20210217-1800/testResults.php |