[issue1112] Test debug assertion in bsddb test_1413192.py
New submission from David Bolen: The change made to Lib/bsddb/test/test_1413192.py to clean up temporary files causes an abort in the DB library when trying to abort an open transaction at object destruction type - currently when the Python interpreter exits, because the transaction log file has been removed. In the Windows debug version this also causes an assertion pop-up dialog window. This has been seen on the 2.5 branch (r57311), trunk (r57286) and py3k branch (57285). The proposed change controls the object lifetime through a wrapper object so the transaction object is destroyed before cleaning up the filesystem. It has the added benefit of permitting the filesystem cleanup to work under Windows since the files are no longer in use. The test still generates a warning about a DBTxn aborted in destructor, but does not abort the interpreter. I have tried testing this without the original (issue 1413192, r42177) change to _bsddb that it was testing, but neither my modified version nor the original seem to crash in my environment, so I can't say absolutely whether or not the proposed change affects what the test was originally designed to test. I suspect subsequent changes to _bsddb.c are perhaps also satisfying the original problem. -- components: Tests files: test_1413192.py.diff messages: 55672 nosy: db3l severity: normal status: open title: Test debug assertion in bsddb test_1413192.py type: crash versions: Python 2.5, Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1112> __ test_1413192.py.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10207] test_file2k crashes under Windows
David Bolen added the comment: Can't really say why it's just hitting now more consistently but the failure is an internal CRT exception during a file close, when it is handed what appears to be an invalid FILE * (the internal structure has bad data). I think it's more chance that it appears to be in the 86819-85819 change. I've been able to generate the same error in 85816 with 4-5 test runs. In all cases it's sporadic, but can trigger just by running test_file2k so doesn't require any other tests to have run. With a local build and the VS debugger, the failure point is the CRT during an internal flush as part of fclose(). The FILE * structure looks like it became corrupted prior to that point. The tail end of the failure traceback is: msvcr90d.dll!_write_nolock(int fh=3, const void * buf=0x00f4e008, unsigned int cnt=1) Line 322 + 0x6 bytes msvcr90d.dll!_write(int fh=3, const void * buf=0x00f4e008, unsigned int cnt=1) Line 75 + 0x11 bytes msvcr90d.dll!_flush(_iobuf * str=0x10311448) Line 154 + 0x1d bytes msvcr90d.dll!_fclose_nolock(_iobuf * str=0x10311448) Line 105 + 0x9 bytes msvcr90d.dll!fclose(_iobuf * stream=0x10311448) Line 57 + 0x9 bytes python27_d.dll!close_the_file(PyFileObject * f=0x00bef5d8) Line 451 + 0x7 bytes python27_d.dll!file_close(PyFileObject * f=0x00bef5d8) Line 651 + 0x9 bytes python27_d.dll!call_function(_object * * * pp_stack=0x0145f228, int oparg=12514776) Line 3996 + 0x10 bytes The last Python runtime code is in the close_the_file frame (fileobject.c, line 451), it's the line: sts = (*local_close)(local_fp) and local_fp has bad pointers inside its structure: local_fp0x10311448 _iobuf * _ptr0x00f4e009 char * _cnt16383 int _base 0x00f4e008 char * _flag 34178 int _file 3 int _charbuf0 int _bufsiz 16384 int _tmpfname 0x char * I've also seem some cases where _ptr isn't explicitly flagged as a Bad Ptr (e.g., value 0x00e56031 with r85816) but is still invalid to access. The local_close code runs outside the GIL, so maybe some sort of race condition with the parent Python file object, though the file object internal file point is NULL'd before releasing the GIL so I don't know if that seems plausible. I'm not sure of the best way to trace back across the C/Python interpreter boundary - the trace above this is really just a lot of PyEval_EvalFrameEx/fast_function/call_function entry points with Python objects that are fairly opaque to the VS debugger. One thing I do find interesting is that sometimes after continuing past the failure point the tests actually run to completion. Not sure if that means the issue might be more in test wrapper code than the tests themselves, or just that continuing past the flush failure in the debugger is something the test can't detect. I'll try to break down the test module later tonight when I have some more time. -- ___ Python tracker <http://bugs.python.org/issue10207> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10207] test_file2k crashes under Windows
David Bolen added the comment: Ok, when it fails, the failure always appears to be one of the FileThreadingTests tests, with the affected close() call occurring within _close_file, called from _close_and_reopen_file, called from _test_close_open_io. It seems tough to backtrace the VS traces to the exact parent test due to the threading involved, but so far I've only been able to see the problem (with some debugging output added) while in test_close_open_print_buffered. It's a little tough to be positive, but I can seem to influence the odds of failure a bit with host I/O load, and I have yet to see a failure if I remove that test, while limiting the FileThreadingTests class to just that test fails with about the same frequency as the original full class did. So even if the issue is more general, that test seems the best way to exercise/analyze it. So there does seem to likely be a real race condition somewhere. -- ___ Python tracker <http://bugs.python.org/issue10207> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11487] build_installer.py should avoid relying on a young Python
David Bolen added the comment: Just a few thoughts that were in part in an earlier exchange with Antoine. It seems to me that if the Python-ast.[ch] files are included in the repository then they ought to be up to date as part of any given change set. So I think I'd actually prefer having them touched in the master copy to avoid needing to be rebuilt (e.g., what presumably has been true up until this most recent change, although I'm not sure if switching to hg has changed something in this area). If that isn't feasible (but the files are still in the repository) then there probably does need to be some way for the build-installer process to permit a more-recent-than-system python to be used. However, it goes to some lengths (understandably) to avoid the risk of corruption from local system files, so it's not clear how to generically make a build script that uses "/usr/bin/env python" to work. Manually touching the output files, either by build-installer, or a separate step in the build process controlled by the master (like the current umask step) seems to be least attractive, since there's no way to know for sure that the files are really up to date that way, right? If they are up to date, then a checkout ought to reflect that, no? -- David -- ___ Python tracker <http://bugs.python.org/issue11487> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11487] build_installer.py should avoid relying on a young Python
David Bolen added the comment: Note that some of my last comment was before I saw the others, so I'm fine with script changes if that seems ok to others. >From Ronald: "This is because the header file and input grammar have the same timestamp, and which forces the rebuild." Note in the buildbot case the .[ch] files have much older timestamps than the generator script. I think if they were the same it would be ok. I suspect this may be an issue now because the old svn approach was a full checkout for each build, whereas the hg approach is to pull to the local clone, and then just update the build tree. So in the svn case all the files would have a good shot at the same timestamp, whereas with the hg approach the generated files get stale if the contents don't change. I wonder if just doing a full checkout from the local clone would be closer to the old svn behavior in general with respect to timestamps and maybe a reasonable policy? -- David -- ___ Python tracker <http://bugs.python.org/issue11487> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11487] build_installer.py should avoid relying on a young Python
David Bolen added the comment: Note in the meantime, I've manually touched those two files on the dmg buildbot and it builds successfully. As Antoine pointed out to me separately, the hg update used by the buildbot should leave that intact, so this should stop any buildbot failures for the time being, or until the source dependencies are touched again. -- ___ Python tracker <http://bugs.python.org/issue11487> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11487] build_installer.py should avoid relying on a young Python
David Bolen added the comment: Guess I cry uncle - not sure how it used to work then. I just did a dummy svn checkout off of the older svn.python.org from trunk and the .[ch] files appear to have dates earlier than the asdl.py script, so I would have assumed it would have the same problem. Yet I don't recall this being an issue on the DMG slave, so guess we were just lucky somehow. -- David -- ___ Python tracker <http://bugs.python.org/issue11487> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12143] packaging extension gcc linking fails on Ubuntu Shared
David Bolen added the comment: I just ran a manual build/test on the buildbot, and these underlying failures appear to be due to the "-l python3.3" option, which can't be found. I also don't see that library in the build tree. Instead, the library is built as python3.3dm (the buildbot process uses --with-pydebug and --with-pymalloc is now default in 3.2+). Haven't dug much deeper than that, so not sure how the packaging tests are figuring out the shared library to link with. I did verify that the sysconfig module variables that are related do all have the dm suffix information so it should be available to the tests. -- David -- nosy: +db3l ___ Python tracker <http://bugs.python.org/issue12143> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10641] kill_python sometimes fails to kill processes on buildbots
New submission from David Bolen : On the XP and Win7 buildbots, kill_python sometimes fails to kill hung processes. I caught one instance recently and gathered some information though not yet enough to identify the issue. I can say that no processes are killed and no error messages displayed. I think that implies either a process ownership-related snapshot failure (which can exit without error) or a failure to identify the processes. I noticed issue10136 and considered it might be related, but in testing I found cases where the exact same usage of kill_python as this failing case worked fine, whereas if it was a path mismatch problem I would expect it to fail consistently. I have attached a log showing the hung processes, attempt to use kill_python, and final successful operation with the pskill utility. In this case it was important to restore the buildbot quickly, but if I can catch it again I'll try to add some debugging code to kill_python first. One thing that confused me along the way is that kill_python is only run at the beginning of a build and not as part of the clean process. So there are cases where I have hung processes around, but they turn out to be killable when the next build starts. I'm wondering if kill_python shouldn't perhaps be used on every clean operation too. -- David -- components: Build files: kill_python.log messages: 123510 nosy: db3l priority: normal severity: normal status: open title: kill_python sometimes fails to kill processes on buildbots type: behavior versions: Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file19964/kill_python.log ___ Python tracker <http://bugs.python.org/issue10641> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10641] kill_python sometimes fails to kill processes on buildbots
David Bolen added the comment: > To kill python_d.exe, you should use kill_python_d.exe instead of > kill_python.exe. Crud, I thought I did. Well, ok, so can't trust this test. > Could you post the buildbot log url? I think this is the last build in the sequence that was failing until I killed the processes: http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/2297 ... the processes had been around for maybe 45 hours at that point, but I can't find the last working run in the waterfall display (I get back to 2252 and then it sort of goes blank). Maybe the main problem is just the sequencing ... the fact that kill_python is only used at the start of a build (but after the svn step) and not during the clean step at the end of a test run? In this case since the svn step was failing it probably never got as far as running kill_python[_d]. -- ___ Python tracker <http://bugs.python.org/issue10641> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10641] kill_python sometimes fails to kill processes on buildbots
David Bolen added the comment: > I think #9973 is rather related. Certainly could be another artifact of a python_d process still executing. In particular though, the suggested patch in that issue agrees with what I was thinking might be needed, in terms of moving kill_python_d over to clean.bat. Can't think of any downsides of applying that change offhand, so if that were to be made, we could just then watch and wait to see if another hung condition occurred. -- ___ Python tracker <http://bugs.python.org/issue10641> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9973] Sometimes buildbot fails to cleanup working copy
David Bolen added the comment: I wonder if it might be better to have kill_python run at the tail end of test.bat, since there's a potential window where losing a connection to the build master might not run the clean step, so still risk blocking a future build after a reconnect due to still running processes. -- nosy: +db3l ___ Python tracker <http://bugs.python.org/issue9973> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8719] buildbot: segfault on FreeBSD (signal 11)
David Bolen added the comment: Wouldn't that module have to be put into the actual source tree, since the tests run beneath the interpreter/libraries that are built for the test? That may be what you meant, but "installed on this host" made me think I could do something external on the buildbot which I don't think would work given that the module has to be called from within the tests themselves? -- David -- ___ Python tracker <http://bugs.python.org/issue8719> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9973] Sometimes buildbot fails to cleanup working copy
David Bolen added the comment: Probably - it's just a general sequencing change, so I suppose should apply equally to all platforms. I suppose even better would be to consolidate the two clean scripts into one (with a parameter for 32 v. 64), but just patching both is less of a change. Unrelated, but it's interesting how the amd64 script makes sure to be in the PCBuild tree before deleting byte compiled files, but the standard script doesn't. Oh, I should probably also update my prior thought in this ticket, since based on a python-dev thread Hirokazu pointed out that just having things at the end of test.bat could be exposed if the actual test itself never returns to the script. That might have higher odds than the build master losing contact with the slave between build and clean step, so the original patch is likely the better choice. Or maybe do it in both both places. But just moving things to clean first would cover the vast majority of cases I seem to see on my build slaves, which only rarely lose contact with the master. -- ___ Python tracker <http://bugs.python.org/issue9973> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9931] test_ttk_guionly hangs on XP5
David Bolen added the comment: Perhaps somewhat orthogonal to the patch, but in terms of the original hang issue, does your service definition have the "interact with desktop" option checked? That ought to permit any normal UI processing to take place as if you were running it interactively. -- nosy: +db3l ___ Python tracker <http://bugs.python.org/issue9931> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9931] test_ttk_guionly hangs on XP5
David Bolen added the comment: If I recall correctly, if you're not using localsystem then its much tougher, as by default it won't have access to your interactive desktop, just something internal that you won't see, maybe just a hidden windows station. You're right that the interact setting is only for localsystem. It's been many years, but I think I had some code that located and attached to the interactive desktop (if one was currently available) from within a background service that I used in a remote management system. Our remote service (functioned similarly to rshd) also ran under a specific user. At least in theory I think you might be able to tweak the local buildbot code to execute any tests from within a child process that does the same thing first. In the end it's only the executing test code that needs the access, not the buildbot itself. If I get a chance I'll see if I can scrounge up what I did, but will take that off-line from this ticket since it's a broader question. -- ___ Python tracker <http://bugs.python.org/issue9931> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8421] tiger buildbot: unable to resolv hostname address
David Bolen added the comment: Looks like some initial configuration glitches - the buildbot needed a little convincing to go to the DNS server for gethostbyname(). Should be working now. -- ___ Python tracker <http://bugs.python.org/issue8421> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8453] build_installer.py breaks bzip compilation
David Bolen added the comment: I believe it's XCode 2.4.1. I know the script worked fine prior to the change that clears the environment, and commenting out just that piece of the latest trunk copy continues to work. To be honest, I'm not sure how the build even finds gcc-4.0 (e.g., why it doesn't fail until ld) once PATH is cleared, nor do I fully understand the change. How is the process supposed to work without a PATH? -- ___ Python tracker <http://bugs.python.org/issue8453> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8453] build_installer.py breaks bzip compilation
David Bolen added the comment: The buildbot user's shell is also bash, so not entirely sure yet why it's behaving differently in my environment. I had completely forgotten about bash having a default path. I do agree that explicitly setting a minimal path is a good idea. -- ___ Python tracker <http://bugs.python.org/issue8453> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8475] build-installer fix for doc building on OSX 10.4
New submission from David Bolen : The attached suggested patch changes build-installer to pass along the same Python executable that it itself is running under to the documentation Makefile. This fixes an issue on OSX where pruning the PATH reverts to the system python (2.3.5) which is too old for Sphinx. This does now mean that build-installer itself needs to be run under 2.5+ which contradicts its initial usage comments. I suspect we should just give up supporting it under 2.3, since an underlying tool no longer supports that, but have not changed those comments in this patch -- assignee: ronaldoussoren components: Macintosh files: build-installer.diff keywords: patch messages: 103790 nosy: db3l, ronaldoussoren severity: normal status: open title: build-installer fix for doc building on OSX 10.4 type: compile error versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file17014/build-installer.diff ___ Python tracker <http://bugs.python.org/issue8475> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8476] build-installer fix for setIcon when no script path specified
New submission from David Bolen : The attached suggested patch fixes a small bug where if you execute the build-installer script without an explicit path (e.g., "python build-installer.py") the setIcon compilation will fail since dirname(__file__) is an empty string, so it ends up looking for files beneath "/". It also normalizes the function slightly, since part of the previous code explicitly used dirname(__file__) whereas part of the code just assumed the output directory was relative to the current directory. -- assignee: ronaldoussoren components: Macintosh files: build-installer.diff keywords: patch messages: 103791 nosy: db3l, ronaldoussoren severity: normal status: open title: build-installer fix for setIcon when no script path specified type: compile error versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file17015/build-installer.diff ___ Python tracker <http://bugs.python.org/issue8476> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8455] buildbot: test_urllib2_localnet failures (Connection refused) on Tiger buildbot
David Bolen added the comment:
For what it's worth, I added a few debugging statements to a local trunk
checkout, and it looks like the port is getting lost somewhere along the way to
setup the proxy... So the refused error is accurate and because it's trying the
default port 80. Note also that I think all the Proxy tests fail, even those
saying they're ok, because the refused error shows up as a URLError which is
what the test expects, but for other reasons.
Oh, and small item I noted while doing the test - the urllib2_localnet module
doesn't clean up properly during the tests - all the local servers are left
listening on their ports until all the tests are done. Adding a call to
self.httpd.server_close() at the end of run() in LoopbackHttpServerThread
appears to fix that.
Here's a sample of one test...
test_proxy_qop_auth_int_works_or_throws_urlerror
(test.test_urllib2_localnet.ProxyAuthTests) ... Init done
Serving HTTP on localhost port 55161
Thread running
Calling handle request
proxy_url: http://localhost:55161
proxy_open: http None None localhost:55161
httplib _set_hostport(localhost,None)
httplib _set_hostport done host=localhost port=80
httplib.connect: Connecting to ('localhost', 80)
back from handle request
--
___
Python tracker
<http://bugs.python.org/issue8455>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://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
[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
[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: 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
[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
[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
[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
[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
[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:
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
[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
[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: 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: 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
[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'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
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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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: 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
[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
[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
[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
[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
[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
[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
[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: 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: 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
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: 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
[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
[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: 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
[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
[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
[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: 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
[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
[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
[issue13507] Modify OS X installer builds to package liblzma for the new lzma module
David Bolen added the comment: I recently built the xz library on my OSX Tiger buildbot (that also does the daily DMGs via the build script), and Nadeem mentioned this ticket. As an FYI, I wasn't able to get the xz library (5.0.3) to configure/build as a universal build (i386/ppc) in a single step (as in the build script recipes). It appears to use some compile options incompatible with multiple -arch. For my buildbot, I built it twice (as i386 and ppc) and then combined the libraries (static and shared) using lipo. This appears to work for both the regular buildbot and the DMG creation. In peeking at the build script this approach is a bit beyond the current recipe process, so would need more work than just a new recipe. Assuming a build/lipo process is considered legitimate for release installers, of course, I'm not that sure how much I ended up "cheating". -- nosy: +db3l ___ Python tracker <http://bugs.python.org/issue13507> ___ ___ Python-bugs-list mailing list Unsubscribe: http://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
[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: 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
[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
[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
[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 <http://bugs.python.org/issue30796> ___ ___ 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
[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: 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: (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: > 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: (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: 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: 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: 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
[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
<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 <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: 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 <http://bugs.python.org/issue30126> ___ ___ 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 <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: 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 <http://bugs.python.org/issue30173> ___ ___ 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 <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: 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 <http://bugs.python.org/issue30225> ___ ___ 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
[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
[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
