[issue45806] Cannot Recover From StackOverflow in 3.9 Tests
Change by David Bolen : -- nosy: +db3l ___ Python tracker <https://bugs.python.org/issue45806> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30570] issubclass segfaults on objects with weird __getattr__
David Bolen added the comment: So I'm guessing something is just borderline under 3.9 on Windows. In some manual testing with a standalone build of 3.9 so far for me: -m test.test_pickle always succeeds (executed directly) -m test test_pickle always fails (executed via test module) -m test -w -j1 test_pickle fails, but succeeds on retry The failures seem to always occur in CPicklerTests.test_bad_getattr. I'm not sure how to run that single test via the test module, but limiting to all CPicklerTests tests or all test_bad_getattr tests succeeds even through the test module. The last scenario above (successful retry) has to use -j or else no retry (-w) takes place. That's the path the buildbots are following. -- ___ Python tracker <https://bugs.python.org/issue30570> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30570] issubclass segfaults on objects with weird __getattr__
David Bolen added the comment: I don't know if this is a buildbot, test or 3.9-specific issue but this commit appears to have introduced a permanent initial failure (but success on retry) in test_pickle on both Windows 10 3.9 builders. First failure for my builder at https://buildbot.python.org/all/#/builders/425/builds/450 Fatal Python error: _Py_CheckRecursiveCall: Cannot recover from stack overflow. 0:14:47 load avg: 4.57 Re-running failed tests in verbose mode 0:14:47 load avg: 4.57 Re-running test_pickle in verbose mode The 3.x and 3.10 builders seem fine, and the second try on 3.9 always seems to succeed (perhaps because it's just a single test running at that point), so this is only being reported as a buildbot warning. -- nosy: +db3l ___ Python tracker <https://bugs.python.org/issue30570> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44252] test_ssl and test_httplib.HTTPSTest crash randomly with "Windows fatal exception: access violation" on Windows
David Bolen added the comment: Oddly, it turns out it's the "--junit-xml" parameter during buildbot tests that is making it reproducible there. Pass: python_d -m test.regrtest test_ssl Fail: python_d -m test.regrtest --junit-xml out.xml test_ssl The latter consistently fails all of the time for me manually. I also found what I think is the same commit Pablo just referenced (albeit the cherry pick version on the 3.10 branch) - ea47a8a71ad56ec349f02bf8c6a1d3bf04acabcc. Reverting just that commit as part of the latest 3.10 source passes. -- ___ Python tracker <https://bugs.python.org/issue44252> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44252] test_ssl and test_httplib.HTTPSTest crash randomly with "Windows fatal exception: access violation" on Windows
David Bolen added the comment: The win10 buildbot appears to have this failure consistently (100%) on the 3.10 branch. The first such failure appears to be yesterday (https://buildbot.python.org/all/#/builders/600/builds/79), following commit da8097aaf5a55c23f5b5ddbeffc2d90d06e00d93 - GC changes for mmap. I'm not yet having much luck reproducing manually (which is perplexing given the consistent failures during the automatic tests). I did see one test run where 8 other tests failed instead, but haven't been able to repeat. The 3.x branch also seems to be doing fine on the buildbot while including the same patch that was cherry picked for 3.10. So this could be a false lead, but it might be another place to review. Or for anyone who can at least sporadically get a failure (I'm still trying), something to try reverting. -- nosy: +db3l ___ Python tracker <https://bugs.python.org/issue44252> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43709] Windows Tools\buildbot\clean.bat misses some needed pyc/pyo removal
David Bolen added the comment: No longer needed after commit c368ce74d2c9bcbf1ec320466819c2d4768252f7 -- resolution: -> out of date stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43709] Windows Tools\buildbot\clean.bat misses some needed pyc/pyo removal
David Bolen added the comment: Based on further information in issue #27129 as well as issue #43719 it appears a source of the problem prompting this fix was a failure to update the magic number in the original commit for #27129. The windows clean script does still leave more artifacts than, for example, the Unix Makefile, but it shouldn't have resulted in a problem if the magic number had changed, and it's not clear it has to change after all. So this issue can probably be closed once that is corrected. -- ___ Python tracker <https://bugs.python.org/issue43709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43719] Master build failure on Windows getting file system encoding
David Bolen added the comment: Dennis, just to make sure I wasn't too literal, some of the __pycache__ folders are in subdirectories (at least in Tools), so just to double check, you did a recursive search beneath Tools and Parser right? -- ___ Python tracker <https://bugs.python.org/issue43719> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43719] Master build failure on Windows getting file system encoding
David Bolen added the comment: Terry, it's not clear to me if this is the same issue (at first blush it appears different) but could you see if you have any pyc files in __pycache__ folders within the Tools or Parser directories in your tree that could be from prior builds? If so, remove them and try a new build? The build.bat script's clean process is not currently cleaning them up, which can lead to various oddities if you reuse a source tree across the commit Victor references, as that invalidates the older files but they aren't regenerated. -- nosy: +db3l ___ Python tracker <https://bugs.python.org/issue43719> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27129] Wordcode, part 2
David Bolen added the comment: I don't think reverting the commit at this point would necessarily be helpful. While it might fix some systems, it could newly break anyone who happened to do their first build since the commit was in place. I didn't want to bug anyone over the weekend, but I've got a PR as part of issue #43709 that I believe would fix this going forward, if anyone with access might have an opportunity to review it. -- ___ Python tracker <https://bugs.python.org/issue27129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43709] Windows Tools\buildbot\clean.bat misses some needed pyc/pyo removal
Change by David Bolen : -- keywords: +patch pull_requests: +23904 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25157 ___ Python tracker <https://bugs.python.org/issue43709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43709] Windows Tools\buildbot\clean.bat misses some needed pyc/pyo removal
David Bolen added the comment: Something like this is a quick 'n dirty minimal fix - at least it seems to solve the problem that arose in issue #27129 on the Win10 buildbot: --- a/Tools/buildbot/clean.bat +++ b/Tools/buildbot/clean.bat @@ -11,6 +11,8 @@ call "%pcbuild%\build.bat" -t Clean -k -d %* echo Deleting .pyc/.pyo files ... del /s "%root%\Lib\*.pyc" "%root%\Lib\*.pyo" +del /s "%root%\Tools\*.pyc" "%root%\Tools\*.pyo" +del /s "%root%\Parser\*.pyc" "%root%\Parser\*.pyo" echo Deleting test leftovers ... rmdir /s /q "%root%\build" but since this only covers the buildbot script, someone working within the regular VS IDE and just using the clean target of the projects could presumably run into the same issue. Or is there some other way to fully clean a working tree from within the IDE? Not sure how important that is to address in any event. -- ___ Python tracker <https://bugs.python.org/issue43709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27129] Wordcode, part 2
David Bolen added the comment: I've opened issue #43709 for fixing the buildbot clean script under Windows. It needs to clean the Tools and Parser trees, not just Lib (and there are a few other folders involved besides clinic) -- ___ Python tracker <https://bugs.python.org/issue27129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43709] Windows Tools\buildbot\clean.bat misses some needed pyc/pyo removal
New submission from David Bolen : The Tools\buildbot\clean.bat script used on Windows only removes pyc/pyo files from the Lib tree, leaving some files beneath Tools (clinic and peg_generator) and Parser (asdl). This can cause failures following commits that affect those files, such as fcb55c0037baab6f98f91ee38ce84b6f874f034a (in issue #27129) leading to subsequent crashes or anomalous behavior. This appears to have been true for a while, though only the 3.10 branch ran into the issue, so any fix might also be back-ported to the other active branches. -- components: Build, Windows messages: 390098 nosy: db3l, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows Tools\buildbot\clean.bat misses some needed pyc/pyo removal type: crash versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27129] Wordcode, part 2
David Bolen added the comment: I'm out of time for a bit, but it appears that the root issue is old pyc files in Tools/clinic/__pycache__ that aren't removed during a clean process, and appear to be the source of all of the errors. Manually pruning that folder fixes things. I believe the regular (non-Windows) makefile automatically prunes all __pycache__ folders in the tree during clean which is probably why that's not an issue on other systems. -- ___ Python tracker <https://bugs.python.org/issue27129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27129] Wordcode, part 2
David Bolen added the comment: Ah, Victor, that helps. I was having trouble reproducing the problem on a different system. I was suspecting a small difference in compiler version, but I hadn't considered it being because I started fresh. >From what I can see, a particular build tree can be successful if it remains >on either side of the instruction commit, but you can't cross the boundary - >in either direction. There's clearly some build artifact not being reset >properly that gets out of sync. I've been able to create odd name errors even >in older commits as long as the first one I build is at or after the >instruction commit. But a pristine checkout on the buildbot of the latest master works, as does a git clean on the tree. I always use the buildbot scripts for building and they invoke a full clean first. So either the clean process on Windows is missing something, or there's an artifact that is supposed to be kept in sync in the source tree itself that isn't. I'm not familiar enough with the internals to guess at which yet. I suppose given that it's not a problem on other buildbots argues for the clean issue, although I suppose it could also be something that is only kept in the tree to benefit a subset of systems, like Windows. (While resetting the checkouts on the buildbot should therefore fix the current exceptions, I'm going to leave that alone for the moment, since that leaves it positioned to confirm any subsequent fix) -- ___ Python tracker <https://bugs.python.org/issue27129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27129] Wordcode, part 2
David Bolen added the comment: Unfortunately, not at the moment - what's in the buildbot log is what's available. The RTL assertion aborts the process. The tests involved (such as test_clinic) do seem reproducible in a few separate tries, though again, all they do is terminate. As the assertion should be correct, I'm guessing it's reflecting an earlier corruption. There's some other oddities, such as the "Leaf" related failures in test_peg_generator that showed up at the same time, in case that offers any hint. Since Leaf and StringLeaf are almost next to each other in grammar.py I can't see how it can be undefined. The worker only has the core build tools version of VS so can't directly debug this further locally. I can look into using a different machine to try to get some details, but I'm not sure as to timing. -- ___ Python tracker <https://bugs.python.org/issue27129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27129] Wordcode, part 2
David Bolen added the comment: Note that this commit appears to be causing exceptions for the Win10 buildbot, failing the PyCode_Addr2Line assertion in codeobject.c line 1252. The assertion seems to pop up at differing points during each test run, but the builder has yet to complete a full test run successfully. -- nosy: +db3l ___ Python tracker <https://bugs.python.org/issue27129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37945] [Windows] test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
David Bolen added the comment:
In lieu of the patch in #25191, what about a pair of skips to deal with the
issues at hand without killing the test entirely? I'm including OpenBSD since
those issues were closed in favor of this one, and am assuming that skipping
there is also appropriate.
--- a/Lib/test/test_locale.py
+++ b/Lib/test/test_locale.py
@@ -552,6 +552,10 @@ def test_setlocale_category(self):
# crasher from bug #7419
self.assertRaises(locale.Error, locale.setlocale, 12345)
+@unittest.skipIf(sys.platform == 'win32',
+ "Test broken on Windows (issue #37945)")
+@unittest.skipIf(sys.platform.startswith('openbsd'),
+ "Test broken on OpenBSD (issues #31636 and #25191)")
def test_getsetlocale_issue1813(self):
# Issue #1813: setting and getting the locale under a Turkish locale
oldlocale = locale.setlocale(locale.LC_CTYPE)
--
___
Python tracker
<https://bugs.python.org/issue37945>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37945] [Windows] test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
David Bolen added the comment: I don't have much of a horse in the race, but since the test has historically been skipped on Windows, and the test hasn't and doesn't work on Windows, modifications to restore the skip behavior seem reasonable to me. The trigger for this issue was Windows adding support for underscore in locale names (like tr_TR) so the test began executing. But it's not a regression or new issue, it's just existing reality becoming exposed. The user machine and buildbot discrepancy can be attributed to version differences, as the buildbot hadn't yet received the same underscore locale name support. I'd be fine with removing the test entirely - always skipping on a failure just seems pointless. Then again, issue1813 created the test for a purpose on other systems, though even back then it appears it was complicated. Leaving the test but skipping known failing systems (I guess at least Windows and OpenBSD) might be slightly less intrusive of a change, assuming the test is still serving a purpose elsewhere. Separately, there's a lot of useful/interesting detail here which could inform any eventual normalization changes on Windows, should the underlying issue be deemed worthy of addressing. But that seems like something that could be a distinct operation from clearing up the test issue. -- ___ Python tracker <https://bugs.python.org/issue37945> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37945] [Windows] test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
David Bolen added the comment: The test has also begun failing on the Win10 buildbot (after updating to 20H2 from an older 1803). -- nosy: +db3l ___ Python tracker <https://bugs.python.org/issue37945> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43271] AMD64 Windows10 3.x crash with Windows fatal exception: stack overflow
David Bolen added the comment: The win10 buildbot is green again, so I think this can be closed. -- ___ Python tracker <https://bugs.python.org/issue43271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43271] AMD64 Windows10 3.x crash with Windows fatal exception: stack overflow
Change by David Bolen : -- keywords: +patch pull_requests: +23510 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24739 ___ Python tracker <https://bugs.python.org/issue43271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43271] AMD64 Windows10 3.x crash with Windows fatal exception: stack overflow
David Bolen added the comment: Yes, that was the idea (revert the PyDEBUG condition only); it sounds like everyone is on the same page. I've been doing buildbot duties only for a while (no code contributions since long before the current process), so there may be a short delay while I figure out this newfangled PR thing... -- ___ Python tracker <https://bugs.python.org/issue43271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43271] AMD64 Windows10 3.x crash with Windows fatal exception: stack overflow
David Bolen added the comment: Steve, where is that configured? If reducing that further would resolve the crashes while retaining ceval debugging, maybe that's a reasonable trade-off, though based on my testing, reverting still seems simpler. Right now the debug build on the buildbot appears use the standard recursion limit of 1000, and some quick grep-fu didn't find a clear spot (either internally or just for the tests) where it would be reduced. Could perhaps how it's done be something that doesn't influence buildbot builds? The failing tests do all appear to be recursion tests of one form or another. Based on further testing, we'd need to have a recursion limit of 290 or below to get most of the test suite to pass. Presumably something like 250 for a bit of head room. However, lowering the limit appears to cover only most of the failures, not all. Some tests directly play with the limits (like test_exceptions.test_recursion_in_except_handler and test_sys.test_recursionlimit_recovery) and still get into trouble, aborting the process, no matter how low the default recursion limit is. so those tests also need changes to pass. In addition, lowering to 290 created one new failure - test_compile.test_extended_arg now fails with a recursion error. It seems to need a limit of about 900 to pass; I guess the test could temporarily reset or something but that seems especially kludgy. Out of curiousity, are these these failures not occurring elsewhere? It seems like something that would be happening in general (at least for anyone compiling debug builds). I thought of checking CI builds, but they appear to use release mode, so would be unaffected. -- ___ Python tracker <https://bugs.python.org/issue43271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43271] AMD64 Windows10 3.x crash with Windows fatal exception: stack overflow
David Bolen added the comment: I hadn't tested release mode earlier, since the commit only removed the pragma in debug builds, but I just built a release build with the commit in place on the worker and it seems fine. So barring stack changes (enlarging or improving usage) it appears the optimize pragma is required on Windows, at least in order to pass the current test suite. -- ___ Python tracker <https://bugs.python.org/issue43271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43271] AMD64 Windows10 3.x crash with Windows fatal exception: stack overflow
David Bolen added the comment: I don't think it's actually any change in ceval per se, or any new buffers, just how the compiler code generation has changed due to this commit. Based on some local testing, the triggering issue is the exclusion of the optimization pragma entirely in debug mode. It appears that the existing code required the pragma to be enabled to stay within the available stack space. A quick reproduction is running test_pickletools. It fails abruptly and quickly, at least on the worker, without the pragma, but runs to completion if enabled. Perhaps that aspect of the commit should be reverted, maybe with a separate flag for debugging ceval (but not normal testing)? Alternatively, is there a way to increase the stack in debug mode to compensate? Though I guess that would risk missing a release-build only stack issue. -- nosy: +db3l ___ Python tracker <https://bugs.python.org/issue43271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43166] Unused letters in Windows-specific pragma optimize
Change by David Bolen : -- nosy: +db3l ___ Python tracker <https://bugs.python.org/issue43166> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41701] Buildbot web page: connection lost after 1 minute, then display "Connection restored" popup
David Bolen added the comment: I was wondering if there was any update on whether or not this new behavior can be corrected? I was attempting to review a buildbot failure today and it's actually pretty tough to "race the refresh" when trying to review the build steps and logs. -- nosy: +db3l ___ Python tracker <https://bugs.python.org/issue41701> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42328] ttk style.map function incorrectly handles the default state for element options.
David Bolen added the comment:
This change to the 3.8 branch appears to be consistently failing on the Windows
7 buildbot (first failing build at
https://buildbot.python.org/all/#/builders/270/builds/126).
It's all failures in the new test_configure_custom_copy and
test_map_custom_copy tests, such as:
FAIL: test_configure_custom_copy (tkinter.test.test_ttk.test_style.StyleTest)
(theme='vista', name='.')
--
Traceback (most recent call last):
File
"D:\cygwin\home\db3l\buildarea\3.8.bolen-windows7\build\lib\tkinter\test\test_ttk\test_style.py",
line 140, in test_configure_custom_copy
self.assertEqual(style.configure(newname), None)
AssertionError: {'foreground': 'SystemWindowText', 'selec[233 chars]bar'} !=
None
and
==
FAIL: test_map_custom_copy (tkinter.test.test_ttk.test_style.StyleTest)
(theme='vista', name='.')
--
Traceback (most recent call last):
File
"D:\cygwin\home\db3l\buildarea\3.8.bolen-windows7\build\lib\tkinter\test\test_ttk\test_style.py",
line 162, in test_map_custom_copy
self.assertEqual(style.map(newname), {})
AssertionError: {'foreground': [('disabled', 'SystemGrayTe[34 chars]1')]} != {}
+ {}
- {'embossed': [('disabled', '1')],
- 'foreground': [('disabled', 'SystemGrayText')]}
Since it seems related to themes, I should mention that the buildbot is running
with a Windows 7 classic (non-Aero) theme with all appearance effects disabled
(the "best performance" option). So I'm not sure if this is an issue with the
code changes, or behavior due to the host environment not anticipated by the
tests.
--
nosy: +db3l
___
Python tracker
<https://bugs.python.org/issue42328>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39010] ProactorEventLoop raises unhandled ConnectionResetError
David Bolen added the comment: I'm guessing the warning appears odd as we're seeing a thread shutdown data race. The message is produced by threading_cleanup in support/threading_helper.py, and it appears that between the first and second lines one of the initially dangling threads goes away, so the only one left to be enumerated is the main thread, at which point the function is simply listing all threads currently alive. But by that point it's just the main thread remaining. I notice in the test that you have a comment about needing to wait for f to complete or you get a warning about thread not shutting down cleanly. Was that a similar warning? The run_until_complete(f) line seems to have no effect on the buildbot. If I added a small sleep at the end of the test the warnings go away on the buildbot. The buildbot is a fairly fast machine, so perhaps the test just needs to wait somehow for the event loop to fully shut down or something. The most direct cause of the warnings seems to be the self.loop.close() call - if I just comment that out the test runs warning-free without any extra delay needed. I don't know much about asyncio tests, but it would appear the close call in the test defeats some of the logic in the close_loop teardown code that runs under TestCase (in utils.py), which under Windows is just a call to run_until_complete(loop.shutdown_default_executor()). If I add that same call to the test prior to the close it also passes cleanly. So if closing the loop in the test itself is crucial, I'd suggest including the extra run_until_complete call. If closing isn't crucial to the test, simply removing it seems to address the issue. I'm not sure if its removal then has any implications for the extra run_until_complete(f) call in the test, as I can't see any impact from that on the buildbot. -- ___ Python tracker <https://bugs.python.org/issue39010> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39010] ProactorEventLoop raises unhandled ConnectionResetError
David Bolen added the comment: I've been seeing failures on the Win10 buildbot 3.x branch that seem to correlate with the timing of this change - could there be some further work needed on Windows? Or, if it's a test-only artifact and the warnings are innocuous, something to ignore the output during the tests? Specifically, the following warnings occur during test_asyncio: Warning -- threading_cleanup() failed to cleanup 1 threads (count: 1, dangling: 2) Warning -- Dangling thread: <_MainThread(MainThread, started 5220)> See https://buildbot.python.org/all/#/builders/146/builds/23 for the first failing build. -- nosy: +db3l ___ Python tracker <https://bugs.python.org/issue39010> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41273] asyncio: proactor read transport: use recv_into instead of recv
David Bolen added the comment: It looks like there was an underlying asyncio.recv_into bug that was the likely root issue here. It's recently been fixed in bpo-41467, and test_asyncio is passing on at least the Win10 buildbot. -- ___ Python tracker <https://bugs.python.org/issue41273> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41467] asyncio: recv_into() must not return b'' if the socket/pipe is closed
David Bolen added the comment: Just for the record, this fix also appears to have resolved the issue with the Win10 buildbot from bpo-41273, which was related to the same unraisable exceptions mentioned in bpo-38912. -- nosy: +db3l ___ Python tracker <https://bugs.python.org/issue41467> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41273] asyncio: proactor read transport: use recv_into instead of recv
David Bolen added the comment: First, I also no longer see the error with a local PR 21446 build on the Win10 buildbot. As for timing, I believe policy is to revert, but in my view it can probably depend on how short "a bit" is for the fix. We've been in this state for 4-5 days already, so one more day, for example, probably won't matter that much. If it looks like it'll be longer, or the timing is uncertain, then I'd probably suggest reverting until the new PR is ready. -- ___ Python tracker <https://bugs.python.org/issue41273> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41273] asyncio: proactor read transport: use recv_into instead of recv
David Bolen added the comment:
I can at least confirm that this commit is the source of the issue on the
Windows 10 buildbot. Interactively, it fails every time with it in place
(unlike the buildbot which has had the occasional success) and passes reliably
with it reverted.
The error arises during the SubprocessProactorTests test suite, but seemingly
not with a specific test, just something that shows up when the entire suite is
run. At least I haven't been able to get it to occur by running individual
tests.
Since the buildbot test output hides the underlying exception, here's the
details of the two unraisable exceptions in question from
test_asyncio.test_subprocess.SubprocessProactorTests. I enabled tracemalloc
but the original allocation is from the common utils module so probably not
that much extra help:
D:\test\cpython\lib\asyncio\windows_utils.py:112: ResourceWarning: unclosed
_warn(f"unclosed {self!r}", ResourceWarning, source=self)
Object allocated at (most recent call last):
File "D:\test\cpython\lib\asyncio\windows_utils.py", lineno 164
self.stdout = PipeHandle(stdout_rh)
D:\test\cpython\lib\asyncio\windows_utils.py:112: ResourceWarning: unclosed
_warn(f"unclosed {self!r}", ResourceWarning, source=self)
Object allocated at (most recent call last):
File "D:\test\cpython\lib\asyncio\windows_utils.py", lineno 166
self.stderr = PipeHandle(stderr_rh)
Exception ignored in:
Traceback (most recent call last):
File "D:\test\cpython\lib\asyncio\proactor_events.py", line 115, in __del__
_warn(f"unclosed transport {self!r}", ResourceWarning, source=self)
File "D:\test\cpython\lib\asyncio\proactor_events.py", line 79, in __repr__
info.append(f'fd={self._sock.fileno()}')
File "D:\test\cpython\lib\asyncio\windows_utils.py", line 102, in fileno
raise ValueError("I/O operation on closed pipe")
ValueError: I/O operation on closed pipe
Exception ignored in:
Traceback (most recent call last):
File "D:\test\cpython\lib\asyncio\proactor_events.py", line 115, in __del__
_warn(f"unclosed transport {self!r}", ResourceWarning, source=self)
File "D:\test\cpython\lib\asyncio\proactor_events.py", line 79, in __repr__
info.append(f'fd={self._sock.fileno()}')
File "D:\test\cpython\lib\asyncio\windows_utils.py", line 102, in fileno
raise ValueError("I/O operation on closed pipe")
ValueError: I/O operation on closed pipe
--
nosy: +db3l
___
Python tracker
<https://bugs.python.org/issue41273>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40826] PyOS_InterruptOccurred() now requires to hold the GIL: PyOS_Readline() crash
David Bolen added the comment: So a script I use on the buildbot intended to prevent hanging on assertions was failing to work in this particular case, which I've corrected. That changes the failure mode for new Win10 buildbot runs. The test in question (test_close_stdin) still fails, but does so immediately (return code not 0, as the child process aborts) rather than timing out. If the assertion is expected, and something to be ignored, the test itself still needs to handle that. -- ___ Python tracker <https://bugs.python.org/issue40826> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40826] PyOS_InterruptOccurred() now requires to hold the GIL: PyOS_Readline() crash
David Bolen added the comment: It appears the recent commit is causing a CRT exception dialog in test_close_stdin (test_repl.TestInteractiveInterpreter). The dialog can't get answered, which is what leads to the eventual timeout. The assertion is "_osfile(fh) & FOPEN" from osfinfo.cpp on line 258. It actually appears twice (if the first is ignored). If both are ignored the test passes. I was somewhat surprised to see the dialog, as I believe CRT exception dialogs are disabled during test runs (others are present in test logs). Perhaps the child interpreter used by test_repl doesn't inherit that behavior. If so, this was probably always a risk, there just weren't any assertions occurring before this in the child interpreter. -- ___ Python tracker <https://bugs.python.org/issue40826> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40826] PyOS_InterruptOccurred() now requires to hold the GIL: PyOS_Readline() crash
David Bolen added the comment: I haven't had a chance to look too deeply, but the final set of commits (starting with fa7ab6aa) appear to be the common thread with all branches now failing with timeout exceptions in test_repl on the Windows 10 buildbot. The first instance was in the 3.x branch (https://buildbot.python.org/all/#/builders/129/builds/1191) but they all seem similar. -- David -- nosy: +db3l ___ Python tracker <https://bugs.python.org/issue40826> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36876] [subinterpreters] Global C variables are a problem
Change by David Bolen : -- nosy: -db3l ___ Python tracker <https://bugs.python.org/issue36876> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.
Change by David Bolen : -- nosy: -db3l ___ Python tracker <https://bugs.python.org/issue33608> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27973] urllib.urlretrieve() fails on second ftp transfer
David Bolen added the comment: Ok, I can confirm that the updated PR 17774 test passes under Windows (and still cleans up after itself). -- ___ Python tracker <https://bugs.python.org/issue27973> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27973] urllib.urlretrieve() fails on second ftp transfer
David Bolen added the comment: I'd be happy to test an updated PR 17774 on a Windows builder, but I don't actually see any change yet. It still appears to hold the earlier NamedTemporaryFile with mode='w' change from a few days ago. -- ___ Python tracker <https://bugs.python.org/issue27973> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27973] urllib.urlretrieve() fails on second ftp transfer
David Bolen added the comment:
The issue appears to be the temporary flag (O_TEMPORARY) that is used under
Windows with delete on close temporary files. That appears to prevent any
separate access to the file by anyone else including obtaining another
reference in the same process:
>>> temp = tempfile.NamedTemporaryFile()
>>> temp, temp.name
(', mode 'w+b' at 0x017958E8>, 'd:\\temp\\tmp44kugh')
>>> other = open(temp.name, 'r')
Traceback (most recent call last):
File "", line 1, in
IOError: [Errno 13] Permission denied: 'd:\\temp\\tmp44kugh'
Changing the mode (PR 17774) of the temporary file has no effect. Setting
delete=False will work, but would defeat the point of using NamedTemporaryFile
for the cleanup.
I don't see any way to have both auto-delete and the ability to write
separately to a file under Windows with NamedTemporaryFile.
Perhaps instead use test.support.temp_dir for the overall test, and let it take
care of the iteration temp files when cleaning up the entire directory?
Something like:
with test_support.temp_dir() as td:
for i in range(self.NUM_FTP_RETRIEVES):
urllib.FancyURLopener().retrieve(self.FTP_TEST_FILE,
os.path.join(td, str(i)))
That seems to work fine under Windows.
--
nosy: +db3l
___
Python tracker
<https://bugs.python.org/issue27973>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38547] test_pty fails when using setsid()
David Bolen added the comment: I think fixing the underlying pty issue should certainly be the goal, but the question is whether the process group change should remain active in the meantime, as its presence is causing a regression in the tests. I think such cases in the past are usually rolled back, right? I was originally on the fence since process groups address a real problem, especially in interactive testing, while creating an arguably aesthetic issue for my case of the buildbots (a warning rather than failure). But Pablo's point about a normal manual full test run failing (not a warning as with the buildbots) feels persuasive since that's probably as common as the issue being addressed by the change. Even if pre-existing, the pty failure is exposed by the process group change, so it might be best for the process group change to wait on fixing the pty issue. I don't know how to weigh the relative impact though, e.g,. how many people are likely to run into each failure case. There's probably more people doing a normal test run than breaking out of such tests though. At the least, it's a worst impact than just the warnings on the buildbots. Perhaps an intermediate fallback could be gating the process group change behind a regrtest option (opt-in) which could then preserve its benefits upon request, without negatively impacting the default test process, whether manual or on the buildbots. At least until resource is available to resolve the pty issue. -- ___ Python tracker <https://bugs.python.org/issue38547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38547] test_pty fails when using setsid()
Change by David Bolen : -- nosy: +db3l ___ Python tracker <https://bugs.python.org/issue38547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38502] regrtest: use process groups
David Bolen added the comment: I can recreate this manually by running regrtest.py against test_pty. Crashes with any "-j#" option, but fine when run sequentially. Removing the process group change avoids the crash. With the process group change in place, the trigger point appears to be the final "os.close(master_fd)" in PtyTest.test_basic. Commenting that out avoids the crash. -- ___ Python tracker <https://bugs.python.org/issue38502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38502] regrtest: use process groups
David Bolen added the comment: I don't know for sure that this is the cause but both 3.x builds following this commit on my bolen-ubuntu worker (Ubuntu 18.04.3) have had test_pty crash in the first attempt, with the retry succeeding. For example https://buildbot.python.org/all/#/builders/141/builds/2679 In spot checking, the same behavior seems to be occurring on many other non-Windows builders as well, presumably those for which it gets used. There doesn't seem to be anything useful produced by the first crash. Just an entry for "test_pty crashed (Exit code -1)" in the test log. -- nosy: +db3l ___ Python tracker <https://bugs.python.org/issue38502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36670] regrtest: win_utils decodes typeperf output from the wrong encoding (test suite broken due to cpu usage feature on win 10/ german)
David Bolen added the comment: I've confirmed the partial read with some local modifications, and the failures are always split between time stamp and value: Warning -- Failed to parse typeperf output: '"10/02/2019 17:42:26.229"' 0.0 Warning -- Missing first field: ,"0.00" 0.0 Adding multiple variables to the typeperf command can vary the split position, but I've only seen it at a variable boundary (starting with the comma). So I'm guessing with the current implementation the above is probably the only point where the I/Os can be interleaved. Also, CRLF seems to only appear at the start of each read, never at the end. You can see that behavior interactively too where the cursor waits at the end of the line between samples. So changes to wait for a complete line to be read would also delay load values by one sample interval. So I'm thinking just reverting to silently ignoring this case is probably simplest. -- ___ Python tracker <https://bugs.python.org/issue36670> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36670] regrtest: win_utils decodes typeperf output from the wrong encoding (test suite broken due to cpu usage feature on win 10/ german)
David Bolen added the comment: Oh, I agree it's just a warning, and I suspect few people look into warnings, but since it's not from an actual test, I'm not sure the overall build should be flagged. The manual typeperf looks fine, but there's no way I could tell visually how the I/O is being done under the covers. My bet is typeperf is probably issuing multiple output calls, one for the leading timestamp and then one for each value. So regrtest just happens to interleave its own read in between the two. The subsequent read would then get the trailing "," which the current code would parse normally as it only cares about the second field. In which case it's not even affecting the load monitoring, other than the warning message. I suspect it's happening on the Windows 10 buildbot as the machine is reasonably fast. But to your earlier comment about things just working previously, I'm not sure there's that much value in adding code to deal with this case. I'd probably just remove the warning to restore the earlier behavior. The current code still ignores other issues like an actual read failure in read_output. Or, if there's a way to generate the message without it being considered an overall test build warning, that would work too. -- ___ Python tracker <https://bugs.python.org/issue36670> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36670] regrtest: win_utils decodes typeperf output from the wrong encoding (test suite broken due to cpu usage feature on win 10/ german)
David Bolen added the comment: Just an FYI that this change is generating warnings on my Windows 10 buildbot with some regularity about a failure to parse testperf output, such as: Warning -- Failed to parse typeperf output: '"10/01/2019 07:58:50.056"' from https://buildbot.python.org/all/#/builders/217/builds/487 Now, clearly there's no queue length in that output so the parsing warning is accurate, but does the overall build have to reflect a warning in such cases, given that it's just a test harness issue, and not anything going wrong with the actual tests? Previously any such cases would be ignored silently, so this probably isn't a new issue but just one that is now shows up as an overall build warning. I don't know why both fields aren't present although it seems plausible that it's just a partial line from the I/O (I don't think it guarantees it receives full lines), and the queue length field would appear on the following read. -- nosy: +db3l ___ Python tracker <https://bugs.python.org/issue36670> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36876] Global C variables are a problem.
David Bolen added the comment: The new test_check_c_globals.ActualChecks test is failing with an "unexpected success" on the bolen-ubuntu buildbot (under Ubuntu 18.04.3). I can reproduce the failure in a manually built tree. -- nosy: +db3l ___ Python tracker <https://bugs.python.org/issue36876> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36511] Add Windows ARM32 buildbot
David Bolen added the comment: Yeah, I think you're right. It looks like without an explicit code, it won't propagate the result as the exit code of cmd itself for those cases where cmd does exit (which would include the buildbots). -- ___ Python tracker <https://bugs.python.org/issue36511> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36511] Add Windows ARM32 buildbot
David Bolen added the comment: I've been investigating issues with test failures on my Windows buildbots seemingly not showing up in the master's web interface (but just showing warnings), and it appears likely due to this change. For example, test_urllib (a test problem from issue 36948) was failing but only appeared as a warning (the first such case on my Win10 builder for example is https://buildbot.python.org/all/#/builders/3/builds/2661). This change appears to force the exit code of test.bat to be successful (0) regardless of the results of the test run, thus obscuring any test failures from a parent process such as the buildbot. As an aside, it also looks like any failures along the new arm32ssh branch would be obscured, assuming that the ssh operation would otherwise have propagated the remote exit code. I think just leaving off the exit code (so just "exit /b") should propagate the rt.bat result properly. Or, a goto to a label at the end of the file and letting it exit naturally would mimic the prior behavior. -- nosy: +db3l ___ Python tracker <https://bugs.python.org/issue36511> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36948] NameError in urllib.request.URLopener.retrieve
David Bolen added the comment: Oh, and just for historical purposes, it looks like the root cause was that the nturl2path.pathnametourl forces an uppercase drive letter. So that's where the inconsistency in the test got introduced. -- ___ Python tracker <https://bugs.python.org/issue36948> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36948] NameError in urllib.request.URLopener.retrieve
David Bolen added the comment: Yes, PR 13476 tested locally on the Win10 builder resolves the error. -- ___ Python tracker <https://bugs.python.org/issue36948> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36948] NameError in urllib.request.URLopener.retrieve
David Bolen added the comment: Since this patch was introduced to the 3.x branch my Windows 7 and 10 buildbots have been failing in test_urlopener_retrieve_file. See https://buildbot.python.org/all/#/builders/3/builds/2661 for the first such failure on the Win10 worker. The problem appears to be related to those workers having an explicit TEMP folder that happens to use a lowercase drive letter, causing the test assertion to fail due to differing case in the drive letter. While I could work around this by changing my builder TEMP definition, the test seems fragile on case-insensitive filesystems, so perhaps it should be comparing a normalized path instead? -- nosy: +db3l ___ Python tracker <https://bugs.python.org/issue36948> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36749] PPC64 AIX 3.x: compilation issue, linker fails to locate symbols
David Bolen added the comment: I think I'm the wrong David for this... -- ___ Python tracker <https://bugs.python.org/issue36749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11871] test_default_timeout() of test_threading.BarrierTests failure: BrokenBarrierError
David Bolen added the comment: I should mention that a high level of test parallelism on the part of my worker might have be a contributing factor in this most recent case. The worker was recently upgraded to a faster 4-core VM, but with limited I/O. In a test run the test processes invariably end up stuck on I/O heavy tests, idling the CPUs. So I've been running the tests under -j8, as I found it the most effective combination of supporting tests stuck on I/O while keeping the CPUs busy, but it does mean that in some cases there's a lot pending on the CPUs, and depending on the exact test ordering in a run presumably some more sensitive tests could be impacted. I have in fact seen an increase in random tests generating warnings (fail, then pass) than the worker had previously. I suspect the benefits of the extra parallelism on total test time (-j8 is about 20% faster than -j4) probably isn't valuable enough and will most likely be reducing it a bit. -- nosy: +db3l ___ Python tracker <https://bugs.python.org/issue11871> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36718] Python 2.7 compilation fails on AMD64 Ubuntu Shared 2.7 buildbot with: relocation R_X86_64_PC32 against symbol ... can not be used ...
David Bolen added the comment: Ok, I've resolved this, and the linker errors did actually point at the root issue. They show trying to link extensions against /usr/local/lib/libpython2.7.a which was my test static build of 2.7.16. Arguably this seems an issue in the buildbot build process in that it doesn't sandbox extension building to force linking to the python library being built rather than a random system library, but I can't see spending any time on that. I've purged the 2.7.16 files from the /usr/local tree and things seem to be back to normal I've started a new run for the failing build. -- ___ Python tracker <https://bugs.python.org/issue36718> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36718] Python 2.7 compilation fails on AMD64 Ubuntu Shared 2.7 buildbot with: relocation R_X86_64_PC32 against symbol ... can not be used ...
David Bolen added the comment: Yes, it appears most likely to be the worker environment. I did upgrade the kernel in between builds 250 (good) and 251 (bad), but reverting that still fails, even with the same commit as in build 250. My current suspicion is that a test I did recently with a static 2.7.16 build is influencing the buildbot build process (which might explain why the error seems to involve an -fPIC mismatch in a library). Not sure how yet though. -- ___ Python tracker <https://bugs.python.org/issue36718> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.
David Bolen added the comment: I just noticed that my last message referenced the wrong commit. My test failures were against commit f13c5c8b9401a9dc19e95d8b420ee100ac022208 (the same as Victor). -- ___ Python tracker <https://bugs.python.org/issue33608> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.
David Bolen added the comment:
Eric, I'm also seeing the same Win7 and Win10 worker failures with commit
b75b1a350 as last time (test_multiprocessing_spawn on both, and test_io on
Win7).
For test_multiprocessing_spawn, it fails differently than Victor since no core
file is generated, but I assume it's related in terms of child process
termination. See for example
https://buildbot.python.org/all/#/builders/3/builds/2390 for Win10, where
test_mymanager_context fails with:
==
FAIL: test_mymanager_context
(test.test_multiprocessing_spawn.WithManagerTestMyManager)
--
Traceback (most recent call last):
File
"D:\buildarea\3.x.bolen-windows10\build\lib\test\_test_multiprocessing.py",
line 2747, in test_mymanager_context
self.assertIn(manager._process.exitcode, (0, -signal.SIGTERM))
AssertionError: 3221225477 not found in (0, -15)
--
(3221225477 is C005 which I believe is an access violation)
For some reason, the Windows 7 worker didn't get a test run while your commit
was live, but I can reproduce the same error manually.
For test_io, as before, its a shutdown lock failure:
==
FAIL: test_daemon_threads_shutdown_stdout_deadlock (test.test_io.CMiscIOTest)
--
Traceback (most recent call last):
File "D:\cygwin\home\db3l\python.test\lib\test\test_io.py", line 4157, in
test_daemon_threads_shutdown_stdout_deadlock
self.check_daemon_threads_shutdown_deadlock('stdout')
File "D:\cygwin\home\db3l\python.test\lib\test\test_io.py", line 4148, in
check_daemon_threads_shutdown_deadlock
self.assertIn("Fatal Python error: could not acquire lock "
AssertionError: "Fatal Python error: could not acquire lock for
<_io.BufferedWriter name=''> at interpreter shutdown, possibly due to
daemon threads" not found in ''
--
In manual attempts I have yet to be able to recreate the
test_multiprocessing_spawn failure under Win10 but can usually manage a 25-50%
failure rate under Win7 (which is much slower). The test_io failure on Win7
however, appears to be more easily reproducible.
It's possible I/O is more critical than CPU, or perhaps its impact on latency;
I seem to more easily exacerbate the test_multiprocessing_spawn failure rate by
loading down the host disk than its CPU. I also noticed that the Win10 failure
was when test_io and test_multiprocessing_spawn overlapped.
While I'm guessing this should happen on any low powered Windows VM, if it
would help, I could arrange remote access to the Win7 worker for you. Or just
test a change on your behalf. In fairness, it's unlikely to be useful for any
significant remote debugging but perhaps at least having somewhere you could
test a change, even if just with print-based debugging, might help. And while
it might be an independent issue, the test_io failure rate appears to occur
more reliably than test_multiprocessing_spawn.
--
___
Python tracker
<https://bugs.python.org/issue33608>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36085] Enable better DLL resolution
David Bolen added the comment: Ok, I've verified that on a Win7 system with SP1 but without KB2533625 I get the expected block screen at startup. On my worker (SP1 with KB2533625) it proceeds to the regular installation main dialog. I'm attaching a copy of the install log in the blocking case to the PR as requested there. -- ___ Python tracker <https://bugs.python.org/issue36085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36085] Enable better DLL resolution
David Bolen added the comment: I can help with a Win7 test of the installer, but my currently available systems are all 32-bit - any chance at a 32-bit version of the installer? -- ___ Python tracker <https://bugs.python.org/issue36085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36085] Enable better DLL resolution
David Bolen added the comment: I just wanted to acknowledge that this was breaking on my Windows 7 builder (with a bad DLL load parameter in both pythoninfo and test steps). It looks like I was missing the required KB2533625 (the machine is mostly a virgin SP1 install), so I've installed that now. I've restarted the most recent build and it's already past both previous error points successfully. Windows 7 is clearly on the wane, but as there may still be other systems in a similar state as my worker, the new KB requirement for 3.8 should probably be documented with the release. -- nosy: +db3l ___ Python tracker <https://bugs.python.org/issue36085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.
David Bolen added the comment:
If I can help with testing or builder access or anything just let me know. It
appears that I can pretty reliably trigger the error through just the
individual tests (test_daemon_threads_shutdown_std{out,err}_deadlock) in
isolation, which is definitely less tedious than a full buildbot run to test a
change.
BTW, while not directly related since it was only just merged, and I won't
pretend to have any real understanding of the changes here, I do have a
question about PR 12024 ... it appears HEAD_UNLOCK is used twice in
_PyInterpreterState_LookUpID. Shouldn't one of those be HEAD_LOCK?
--
___
Python tracker
<https://bugs.python.org/issue33608>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.
David Bolen added the comment: I suspect changes for this issue may be creating test_io failures on my windows builders, most notably my x86 Windows 7 builder where test_io has been failing both attempts on almost all builds. It fails with a lock failure during interpreter shutdown, and commit ef4ac967 appears the most plausible commit out of the set introduced at the first failing build on Feb 24. See https://buildbot.python.org/all/#/builders/58/builds/1977 for the first failure. test_io has failed both attempts on all but 3 of the subsequent 16 tests of the 3.x branch. It might be worth noting that this builder is slow, so if there are timeouts involved or a race condition of any sort it might be triggering it more readily than other builders. I do, however, see the same failures - albeit less frequently and not usually on both tries - on the Win8 and Win10 builders. For what it's worth one other oddity is that while having test_multiprocessing* failures are relatively common on the Win7 builder during the first round of tests due to exceeding the timeout, they usually pass on the retry, but over this same time frame have begun failing - not due to timeout - even on the second attempt, which is unusual. It might be coincidental but similar failures are also showing up sporadically on the Win8/Win10 builders where such failures are not common at all. -- nosy: +db3l ___ Python tracker <https://bugs.python.org/issue33608> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35433] Correctly detect installed SDK versions
David Bolen added the comment: Ah, got it (and see the pipelines comment by Steve). Jeremy, I suspect you might actually be able to restart the most recent 3.6 builds on my builders since you were the committer. It changed in Sep to only allow python-core users and the "owner" of the build. Though I don't think I learned for sure if owner was the author of the commit or just the actual committer. I think Zachary was going to look into it time permitting. We probably need a different GitHub group for buildbot owners or something. Separately, I think in the context of this issue I think it's fair to say that the commit need not be rolled back. I have to imagine that anyone trying to build 3.6 using VS 2015 at this point is going to be better represented by Jeremy's worker than mine (in terms of VS point release and default SDK installation), and I expect to be able to resolve any remaining issues worker-side once some 3.6 builds go through. -- ___ Python tracker <https://bugs.python.org/issue35433> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35433] Correctly detect installed SDK versions
David Bolen added the comment: Oh, it's not the installation itself, I'm just wondering if allowing a newer version is ok too? Of course, it doesn't preclude expanding the build script in the future, so I've installed 15063 to both Win8/10 workers. I don't currently have access to restart builds through the buildbot web interface any more, but if someone who does wants to rerun the last 3.6 build on each builder we can make sure this resolves the issue on those workers. I've done a quick manual build that compiles with the exception of not finding midl.exe for pyshellext, but that seems separate (every SDK has the binary) so I'm assuming it's environmental outside of the regular build environment. -- ___ Python tracker <https://bugs.python.org/issue35433> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35433] Correctly detect installed SDK versions
David Bolen added the comment: Hmm, VS2015 started as a full installation (with UI), probably right from its initial release. The build tools only installation (v141) is for VS2017. Best I can tell I'm at update 1 - my update version in the registry is 14.0.24720 (plus I have a .1 installer still in the filesystem). Not sure why I don't have 10586 if that came with update 1. But I wouldn't be surprised if I'm no further. The last time I used the VS2015 installer it completely messed up one of my workers and took a bunch of time to recover from. When switching to VS2017 I think I thought it was going to be preferred for the 3.x series when available, so I probably treated the VS2015 version as less critical. I guess that didn't end up happening for earlier than 3.7. Anyway, best next steps to close out this issue... I assume my installing any matching SDK (say 15063) would allow the workers to match the build script. Alternatively, including more recent SDKs (16299 is the next in line) in the build script would work with the existing workers. I'm fine either way. -- ___ Python tracker <https://bugs.python.org/issue35433> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35433] Correctly detect installed SDK versions
David Bolen added the comment: (and the working log) -- Added file: https://bugs.python.org/file47986/msbuild-win10-good.log ___ Python tracker <https://bugs.python.org/issue35433> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35433] Correctly detect installed SDK versions
David Bolen added the comment: > So before the change, the 16299 SDK wasn't being detected either, but perhaps > the 10240 one was? So I'm just confused It does seems likely that 10240 of the UCRT was being used (based on the attached msbuild logs). Howevr, the UCRT warning in the build process was fine, and said I was using 16299 (see https://buildbot.python.org/all/#/builders/31/builds/717/steps/1/logs/stdio for the last working build on Win10). I'm not sure what to trust - the msbuild log or whatever the ucrtused test is doing for detection? In either case, this issue commmit does seem to force selection of the non-existent 15063 SDK, at least based on msbuild.log - the process doesn't get far enough to run the UCRT version check. Using Win10 for the moment, under "Program Files (x86)" I do seem to have some older UCRT SDKs (in "Microsoft SDKs/Windows Kits/10/ExtensionSDKs/Microsoft.UniversalCRT.Debug") as 10.0.10150.0, 10.0.10240.0 and 10.0.16299.0. Whereas only 10.0.16299.0 exists in the "Windows Kits/10/Platforms/UAP" directory. So I guess msbuild is not strictly picking the "earliest" for UCRT as 10240 isn't quite the earliest. In comparison, my Windows 7 worker also has the 15063 UCRT SDK so the enforced minimum works there for the UCRT path. Of course, the ucrtused test in the build process seems to always say 16299. I ran the requested msbuild command on the Win10 worker as part of PCBuild\build.bat just after the first find_msbuild.bat call. I'm attaching the log files as msbuild-win10-good.log (commit prior to this change) and msbuild-win10-bad.log (after this change). So I guess the question is exactly what do we need to enforce in the build process and/or provide at a minimum on a worker? Should I just install the older 15063 SDK on Win8/10, or should we include some more recent versions in the build time version check? What is a new user trying to build Python likely to have (assuming they're still using VS2015). -- Added file: https://bugs.python.org/file47985/msbuild-win10-bad.log ___ Python tracker <https://bugs.python.org/issue35433> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35433] Correctly detect installed SDK versions
David Bolen added the comment: (sorry for the rapid updates) I'm also fairly sure that none of my workers have update 3 for VS2015. They do however all have VS2017 - but I think VS2015 still gets picked for 3.6 if both are present, right? So that's another variable, in that my workers wouldn't have run into the update 3 issue with the older configuration that Jeremy did. Not sure if there's a way to have the build setup to work for both cases. -- ___ Python tracker <https://bugs.python.org/issue35433> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35433] Correctly detect installed SDK versions
David Bolen added the comment: Oh, since my reading comprehension must be low today, it appears like Jeremy actually had a closer situation previously as I'm in now, with a later (not older) version of the SDK that wasn't in the list. Which is interesting, since he got an error about the SDK whereas my workers weren't having an issue at that point. But I guess it still comes down to what to do if the hardcoded list doesn't match what's on the system, but the SDK on the system will actually work. Complain or let the default get used anyway? -- ___ Python tracker <https://bugs.python.org/issue35433> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35433] Correctly detect installed SDK versions
David Bolen added the comment: Well, correct me if I'm wrong, but installing 15063 would then match one of the checks, and become the selected SDK, so be expected to work fine, right? I think (not sure) that the issue with my Win8/10 workers is they only have the later 16299. So in that case the build process is trying to enforce 10586 as a minimum (due to not finding anything else) which can't work. Assuming I'm interpreting the new WindowsTargetPlatformVersion definition correctly). When you say the "others were going to fail too" I don't think that's correct in all cases. That is, the installed version doesn't match the checked versions, but it's later, so it could work fine. And in this case it's the only version available so the default build tool selection is fine. I'm guessing Jeremy's case was having older (not workable) versions and still not matching one of the checked versions, in which case the build default of oldest would fail. And yes, in that case enforcing a missing version is no real difference since both options fail. Not sure if solving both cases is possible, but at least letting the build tool default to an available SDK if no match is found seems more conservative. It might still fail, but there are cases where it won't. And it seems more likely over time that someone may only have a later SDK than that they'll have an earlier one or a guaranteed match to those being checked. Or if we want to enforce specific versions, publishing them and forcing the build to fail hard would be an option too. I don't think the difference in registry vs. folder checks is an issue, at least not for me. On the Win8/10 workers, both the registry and filesystem are in agreement - the only thing available is 16299. I'm also not sure if it's possible, but it would be great to have some output somewhere about the selection. Right now there's nothing in the compiler stage output of a working vs. failing build to indicate why they are behaving differently. But that's probably a separate topic. -- ___ Python tracker <https://bugs.python.org/issue35433> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35433] Correctly detect installed SDK versions
David Bolen added the comment: I'm not that familiar (ok, at all) with the build process configuration, but in looking at the changes to python.props, it appears to now enforce the minimum in the build process regardless of whether it is found, whereas before the build tool was allowed to pick a default. On my Win8/10 builders, I don't have an SDK that matches anything in the new checks (10586, 14393, 15063), but instead just have a single later (16299) version installed. The Win7 buildbot does, however, also have an earlier 15063. So what happens if none of the checked versions exist? Am I correct that it'll enforce trying to use the minimum (10586) which won't work on my Win8/10 workers since it doesn't exist, while the default behavior to just use the SDK I have would be fine Or is the build tool supposed to ignore the missing SDK and still use a default if later? It seems to me the older default of letting the build tool apply its own defaults if no known matching SDK is found is better than specifying a possibly missing SDK, but obviously the older default caused an issue in Jeremy's original case. And since the prior behavior was just to try to avoid the build tool from defaulting to too old an SDK, another solution to problems in that case might be to remove the oldest SDK, thus moving the default forward. -- nosy: +db3l ___ Python tracker <https://bugs.python.org/issue35433> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33355] Windows 10 buildbot: 15 min timeout on test_mmap.test_large_filesize()
David Bolen <db3l@gmail.com> added the comment: For my buildbots, I suspect win8/win10 should be ok at this point. Among any other changes their local disk appears to be an SSD now, which makes a big difference. I observed steady 250-300MB/s write I/O for the duration of the mmap test, for example, so no wonder that test highlights any I/O bottlenecks. Those two buildbots are independent so it's more a question of running the tests at all versus just on one. On the other hand, win7/winxp compete on the same host, with traditional disks. So including winxp as a slow windows build together with win7 couldn't hurt, although as 2.7 only, winxp runs far fewer tests nowadays. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33355] Windows 10 buildbot: 15 min timeout on test_mmap.test_large_filesize()
David Bolen <db3l@gmail.com> added the comment: The win7 builder isn't on Azure, so changing host type isn't an option at the moment. For my part, I'd prefer removing the largefile tests for that one rather than increasing timeout. The tests generate a huge amount of I/O, so my guess is it's just not practical in the current builder environment. I should note that unlike the win8/win10 builders, there have been no VM or host changes for the win7 builder in quite a while, so if these failures are recent, they can't necessarily be explained by test environment changes. With that said, the win7 builder is certainly resource constrained in terms of CPU and I/O so perhaps the tests were always marginal. Or perhaps the use of -j2 is exacerbating the situation depending on which pair of tests overlap with test_mmap. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33355] Windows 10 buildbot: 15 min timeout on test_mmap.test_large_filesize()
David Bolen <db3l@gmail.com> added the comment: I have migrated the win8 and win10 builders to a different machine type on Azure, which seems to have restored more reasonable performance for the tests, at least in the first set of builds. Assuming that continues to hold true, it should resolve this issue. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33355] Windows 10 buildbot: 15 min timeout on test_mmap.test_large_filesize()
David Bolen <db3l@gmail.com> added the comment: A longer timeout might be another workaround, but for myself, I tend to favor Zachary's original suggestion of eliminating largefile tests for the moment as simplest and most robust. It would also reduce the overall percentage of test time currently spent on a small number of tests. Time (and budget) permitting, I do hope to try some tests on newer Azure machine types to see if they behave differently, which might be a longer term option. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33355] Windows 10 buildbot: 15 min timeout on test_mmap.test_large_filesize()
David Bolen <db3l@gmail.com> added the comment: Disk space seems unlikely as a reason - the local disk is 60GB on each buildbot, of which at least 50GB+ is generally free. So that shouldn't be a problem (the WinXP/Win7 buildbots operate with far less, like 5-10GB). I had also considered that perhaps something went wrong with the temp folder setting during the reboot so it ended up on the system disk (network) rather than the local disk, but it looks fine, and I see build and temporary files all created on the local disk. I believe some of the worst overheads for Spectre patches were found in I/O intensive workloads. Interestingly, neither buildbot processor reports PCID support, which might make it worse (though I don't know for sure if Azure exposes those flags to guests). Of course, it could just be some other change in the new physical machines in some way. There have been no other guest changes for a while (last was a build tool change in January). Whatever it is, it certainly seems correlated to the maintenance, and appears to be consistent after that point. -- David -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33355] Windows 10 buildbot: 15 min timeout on test_mmap.test_large_filesize()
David Bolen <db3l@gmail.com> added the comment: Nothing for my part, but there was an Azure "maintenance" on 4/16 where both the Win8 and Win10 buildbots were migrated to "newer" hardware (the first change to their physical machine for a really long time). No word on why. The VM machine class was unchanged, and the tests run on a local disk. But perhaps there has been a performance or other impact (Spectre changes?) That seems to line up in terms of timing, for example with Win10 3.x build 795 and Win8 3.x build 831 both running the AM of 4/16 with the first failures. Oddly, I'm having trouble finding a reference to test_mmap in older Win10 3.x build logs, but on Win8 3.x builds it was definitely one of the slower tests before that point, although only in the 4-5 minute range. So not sure. Assuming it was the "upgrade" and given the persistence of the failure since, I suppose it's safer to assume this is a new normal for that platform - if skipping the particular test(s) would work, I say go for it at least for now. -- David -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32248] Port importlib_resources (module and ABC) to Python 3.7
David Bolen <db3l@gmail.com> added the comment: Apologies if this is obvious and already in progress, but the issue with Windows and this change appears to be that the "utf-8.file" file is being treated as text rather than binary. So the line ending is expanding to CRLF. The working copy of utf-8.file on my Windows workers is actually 21 bytes, not 20. -- nosy: +db3l ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32248> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32264] move pygetopt.h into internal/
David Bolen <db3l@gmail.com> added the comment: After some further testing, it does not appear to be configure related but something environmental (maybe MACOSX_DEPLOYMENT_TARGET) - using the same configure options manually as build-installer seems ok. For what it's worth, since there do appear to be duplicate definitions in pygetopt.h and getopt.c, adding "extern" to the declarations in pygetopt.h appears to resolve the issue. It looks like that was lost with the removal of PyAPI_DATA. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32264> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32264] move pygetopt.h into internal/
David Bolen <db3l@gmail.com> added the comment: This commit appears to have broken OSX installer builds using the build-installer.py script (as in the last two attempts on the bolen-dmg-3.x builder), confirmed with a bisection from the first failing worker build (covering the range 02a0a19..3327a2d) It fails during the main python compilation with: ld: multiple definitions of symbol __PyOS_optarg libpython3.7m.a(getopt.o) definition of __PyOS_optarg in section (__DATA,__data) libpython3.7m.a(main.o) definition of __PyOS_optarg in section (__DATA,__common) ld: multiple definitions of symbol __PyOS_opterr (repeated for the various __PyOS__opt* symbols. It doesn't seem to be a problem with a simple manual configure/make build (probably why the regular OSX workers aren't failing). So best guess at the moment is it's related to one of the extra configure options used by the build-installer script. I'm not sure which of the commit or build process needs correction, although reverting this at least temporarily would resolve the immediate issue. -- nosy: +db3l, ned.deily, ronaldoussoren ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32264> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32149] bolen-dmg-3.x: compiled failed with: blurb: command not found
David Bolen <db3l@gmail.com> added the comment: Yeah, I'm not sure if I can do anything on my side. It looks like it's an issue with the build patch (issue30487, commit d8d6b91, assuming that's what Zachary is referring to). The blurb complaint is about something that appears should have been installed in a venv during the build process. If I need to upgrade or install something on the worker to support this change, I can certainly do that, but I don't immediately see what that should be. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32149> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31967] [Windows] test_distutils: fatal error LNK1158: cannot run 'rc.exe'
David Bolen <db3l@gmail.com> added the comment: Ok, so rc.exe appears truly not to be found when the test runs. The binary is a bit buried in the Windows Kit directory tree, and I'm guessing something is off after the upgrade (I'm not sure where it was in the tree before). I manually placed a copy in a directory I know is on the path and that seems to have resolved it. I also found a similar copy of rc.exe from the SDK to a local directory on my Windows 7 worker, so I suspect that was what I was remembering, and I probably hit the same thing when updating the SDK on that worker previously. Not sure if there's some better way it should work, but at least this resolves the issue from the SDK update - builds are currently in progress, but both workers passed test_distutils. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31967] [Windows] test_distutils: fatal error LNK1158: cannot run 'rc.exe'
David Bolen <db3l@gmail.com> added the comment: This seems to correlate with my upgrading to the latest Win10 SDK on those workers (Steve pointed out I was still getting ucrt warnings during compilation). So they both jumped from like 10240 up to 16299. But that's all I changed. Interestingly I only had to fix 8.1 and 10, as 7 already had a version (15063) avoiding the warning, and it's tedious to change. But it's not experiencing the linking problem. I could swear I recall past link/rc problems, but my searching (and memory) are failing me at the moment. But I wonder if that's why I had left these two workers back at 10240, or if I had some local fix in place. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31430] [Windows][2.7] Python 2.7 compilation fails on mt.exe crashing with error code C0000005
David Bolen <db3l@gmail.com> added the comment: Sounds good. I must admit I hadn't actually gone looking for a standalone installer yet, but just assumed it would exist. The Win10 worker now has the .NET 3.5 feature installed (which also installed 2.0 and 3.0). Builds seem fine even after removing the temporary exe config file I had put in place. So I think we should be good for this issue. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31430> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31430] [Windows][2.7] Python 2.7 compilation fails on mt.exe crashing with error code C0000005
David Bolen <db3l@gmail.com> added the comment: Sure, I can certainly do that. Does "basically a requirement" mean it should have been there all along (with the VC9 installation), or just that trying to use VC9 on a recent system like Win 10 safely requires it installed separately? I guess Win 8 was the first version to default to only having 4+ already installed. Oh, any preference between using the OS component setup (windows features) to install vs. downloading an installer? I was thinking of using the features approach since it's easy to document as a requirement for anyone else. I doubt there's much difference in the end result. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31430> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31430] [Windows][2.7] Python 2.7 compilation fails on mt.exe crashing with error code C0000005
David Bolen <db3l@gmail.com> added the comment: I believe I've identified the issue, and put a workaround in place. The 986b7ffc commit somehow affected which binary of mt.exe is being run (for version 5.2.3790.2076, 2005), changing from: C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\x64\mt.exe to C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\mt.exe The 32-bit version is what is crashing, at least when trying to add the manifest to a 64-bit library (it does work for other manifest operations). I thought the binary was just incompatible, but I located a later version of mt (6.3.9600.17336, 2012) under C:\Program Files (x86)\Windows Kits\8.1 for which both the 32-bit and 64-bit versions worked. Of course, there was also the issue of why Win8 was working with the 5.2 32-bit version. Then I noticed a .NET config file for the newer 6.3 mt to handle running on systems with .NET 4 but not 1.1 or 2. As it turns out, the Win10 buildbot is .NET 4+ only, while the older 8.1 buildbot has frameworks back to .NET 2. So that's probably what kept the Win8 buildbot from failing just like Win10. What I did for now is borrow the .NET exe config files from mt 6.3 for use with the SDK mt 5.2 binaries, which looks like it's done the trick. It might be best to restore the old behavior if possible so building works without the workaround, but I'm not sure how the binary is being determined. None of the mt binaries are in the default path so must be found by the build process somehow. Reverting to using env.bat with the latest source (so msbuild is found on the path) still ends up calling the 32-bit mt. So something else in the changes must be influencing the binary choice. And given that this only affects using the scripts to build 2.7 on a recently installed machine, hard to say if it's worth much effort. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31430> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30796] Failures/crashes in test_signal on some buildbots
David Bolen added the comment: Antoine, yes. Send me your public key (db3l.net at gmail) and I'll set it up. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30796> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30225] EBADF error on x86 Tiger 3.x buildbot
David Bolen added the comment: In running the test under a local build, the issue is very repeatable, but I believe it's actually due to slow process startup rather than a quick exit. That is, adding a brief sleep after process creation and just before the Request() call seems to fix the problem. I'm guessing the buildbot is sluggish enough that it just takes a bit longer for the process to start and be ready to be used. Whether or not that's purely a machine or test problem, or whether it means that perhaps subprocess.Popen() is returning sooner than it should with a process that isn't ready yet is unclear. (Or even if subprocess can tell) With the machine fairly idle, it looks like the minimum workable delay is about 200ms - probably something a bit longer would be safer under load, if looking for a quick workaround. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30225> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30225] EBADF error on x86 Tiger 3.x buildbot
David Bolen added the comment: Hmm, I wonder if this is another race condition similar to issue 8458? I think that was thought to be related to the subprocess exiting quickly, in which case the question might be why that might happen more so than the actual descriptor error. BTW, Victor, in case it would help, your account (vstinner, ssh key haypo@marge) still exists on this buildbot from past testing in 2011. The only thing I'd need to re-enable is the port forwarding on my firewall. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30225> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30173] x86 Windows7 3.x buildbot has the issue #26624 bug
David Bolen added the comment: Yeah, there were a few transient build errors while I was getting the buildbot back online. My initial attempt to fix this ticket involved using the VS 2015 installer which turned out very badly, so I had to fall back to an older VM image and start over. But the older image had an older buildbot version which didn't work with the git workflow, which hit a few pending builds before I got it fixed. I'm not yet sure if there may be some other fallback (e.g., the link error in the recent 3.x build seems familiar but I can't recall why offhand) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30173> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30173] x86 Windows7 3.x buildbot has the issue #26624 bug
David Bolen added the comment: Ok, I believe I've got the latest ucrtbased now on the Win7 buildbot (validate_ucrtbase.py reports it as 10.0.15063.137). It appears as if my Win8 and Win10 buildbots also have the older dll, so I'm guessing they're just fast enough or lucky enough not to run into the issue. I'll plan on addressing them in the near future as well. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30173> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30126] CheckTraceCallbackContent of test_sqlite3 fails on OS X Tiger
David Bolen added the comment: Ok, this should be resolved. I opted to be a bit more conservative and only upgraded to sqlite3 3.8.3.1, which is the oldest version still in use for the dmg installer packages (for 2.7). I restarted the most recent 3.x build and while it's not completely done yet, the sqlite tests have passed. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30126] CheckTraceCallbackContent of test_sqlite3 fails on OS X Tiger
David Bolen added the comment: The test appears to pass against a local test build of sqlite3 3.18.0, so I'll probably just plan on updating the slave to that later tonight. Unless anyone is interested in figuring out why it fails with 3.6.11 and not 3.18.0 (e.g., does the test have a higher minimum version than it currently declares). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30126] CheckTraceCallbackContent of test_sqlite3 fails on OS X Tiger
David Bolen added the comment:
No recent changes to the buildbot (I think the last was in September to bump
the local python used to run the slave/build installer to 2.7).
The default system sqlite (/usr/lib) is 3.0.8.6, so extremely old, but 3.6.11
is in /usr/local/{lib,include} from early days of setting up the slave, so only
marginally less old. As long as the python build process finds that (which it
appears to) it should be consistent.
I configured and built a local 3.x branch version of python on the slave and
modified it to dump the version info during module initialization:
> ./python.exe
Python 3.7.0a0 (heads/master:d1ae24e, Apr 21 2017, 15:06:29)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
SQLITE_VERSION: 3.6.11
SQLITE_VERSION_NUMBER: 3006011
sqlite3_libversion: 3.6.11
so it appears to be in line. This local build still fails the test.
Maybe whatever feature is needed for this test is broken with 3.6.11.
One thing I did notice, though I suspect it's not an issue, but the 3.6.11 this
slave is using seems to fall into the gap in the original bpo-9303 _v2 support
patch where a _v2 prepare with a plain close (versions >= 3.3.9 and <3.7.14).
Both plain and _v2 close methods have the same signature, but I wonder if there
might be an issue mixing and matching?
I don't think anything else has a hard dependency on my /usr/local libraries on
the slave at this point (the dmg installer builds its own local copies), so I
could try updating that to a more current sqlite3 if we wanted to see if that
resolved the issue.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30126>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
