Jeremy Kloth added the comment:
The test only completed once I purposefully terminated the offending Python
process. The only identifying information I noticed was the command-line of
`-c "while True: pass"`, indicating it was stuck in either
test_call_timeout() or test_ti
Jeremy Kloth added the comment:
I've been able locally to reproduce the test_subprocess hang. The responsible
function is subprocess.run(). The test case, test_timeout(), uses a small
timeout value (0.0001), which, when given enough load, can cause the run() call
to hang.
A judiciou
Jeremy Kloth added the comment:
> > the fix should be as simple as coercing the timeout values to >= 0.
>
> Popen._remaining_time() should return max(endtime - _time(), 0).
That was my first initial instinct as well, however, that change would
also affect more of the Popen beha
New submission from Jeremy Kloth :
While the current build does enable building of projects in parallel
(msbuild -m), the compilation of each project's source files is done
sequentially. For large projects like pythoncore or _freeze_module this can
take quite some time.
This simp
Change by Jeremy Kloth :
--
keywords: +patch
pull_requests: +29535
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31390
___
Python tracker
<https://bugs.python.org/issu
New submission from Jeremy Kloth :
When attempting to run the test harness, I receive the following:
Traceback (most recent call last):
File "", line 198, in _run_module_as_main
File "", line 88, in _run_code
File "C:\Public\Devel\cpython\main\Lib\test\__main__.
Change by Jeremy Kloth :
--
nosy: +vstinner
___
Python tracker
<https://bugs.python.org/issue46788>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Jeremy Kloth :
A recent change to the buildmaster config effectively disabled the caching of
the externals for Windows buildbots:
https://github.com/python/buildmaster-config/pull/255
If the caching is desired, a simple change to the buildmaster config is needed
Change by Jeremy Kloth :
--
nosy: +pablogsal, vstinner
___
Python tracker
<https://bugs.python.org/issue46789>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Jeremy Kloth :
As a follow on to bpo-46716, the various timeout parameters currently deal with
negative values differently in POSIX and Windows.
On POSIX, a negative value is treated the same as 0; check completion and raise
TimeoutExpired is still running.
On Windows
Change by Jeremy Kloth :
--
nosy: +eryksun, vstinner
___
Python tracker
<https://bugs.python.org/issue46790>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
Oh, I forgot to add that I'm in favor of following the threading.py behavior of
allowing <=0 to mean "non-blocking" (i.e., just check). This would probably
also benefit from a documentation
Jeremy Kloth added the comment:
I personally would like to see caching restored so as to keep the duration of
buildbot runs as low as possible. The repeated fetching effectively doubles
compilation time for my Win11 builder.
--
___
Python
Jeremy Kloth added the comment:
> Would it be possible to create a download cache somewhere outside the Python
> source tree, so "git clean -fdx" would not remove this cache?
I was thinking of locating it next to the checkout directory. The
current structure is:
[worker r
Jeremy Kloth added the comment:
Good news, the difference on Windows was easy enough to find, bad news total
refs are now negative!
--- a/Objects/exceptions.c
+++ b/Objects/exceptions.c
@@ -3647,8 +3647,7 @@ _PyBuiltins_AddExceptions(PyObject *bltinmod)
#define INIT_ALIAS(NAME, TYPE
Jeremy Kloth added the comment:
Note that an allocated block is still leaking.
Strange as well, when using dump_refs, the total refs are much more negative
(-12 linux, -13 Windows)
--
___
Python tracker
<https://bugs.python.org/issue46
Jeremy Kloth added the comment:
> Oh wow. How did you find this leak? Did you read all C files and check for
> code specific to Windows? How did you proceed? Well spotted!
Initially, I modified Py_INCREF to dump the object (addr & tp_name) on
initial inc (ob_refcnt == 1) and Py
Jeremy Kloth added the comment:
> ./configure --enabled-shared --with-py-debug --with-trace-refs
(that's what I get for typing from memory):
./configure --enable-shared --with-pydebug --with-trace-refs
> > I proposed GH-31594 to fix this macro.
>
> Even using that
Jeremy Kloth added the comment:
Did you also modify initconfig.c? That part is required as the usual
processing of the environment variable PYTHONDUMPREFS needed to enable
tracing output is ignored with -I
--
___
Python tracker
<ht
Jeremy Kloth added the comment:
The attached patch seems to work as-is. That is, just testing for `self.path`
as the prefix. On Windows, at least, the paths in RECORD are always absolute.
Further changes will be necessary, of course, once changes for alternative
paths (--prefix, --home
Jeremy Kloth added the comment:
Please read the link which you posted. Quoting the second paragraph, second
sentence:
"Default namespace declarations do not apply directly to attribute names;"
and from the third paragraph, third sentence:
"The namespace name for an unpre
Changes by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<http://bugs.python.org/issue12729>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
The failure was due to the sdist command having different default formats for
each platform (i.e., POSIX: gztar, Win32: zip). Patch attached.
--
keywords: +patch
nosy: +jkloth
Added file: http://bugs.python.org/file22952/test_sdist.diff
Changes by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<http://bugs.python.org/issue12895>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<http://bugs.python.org/issue11805>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<http://bugs.python.org/issue6792>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<http://bugs.python.org/issue10175>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
A quick look with Dependency Walker gives me the following:
Python 2.4,2.5 -- MSVC .NET 2003 (7.1)
Python 2.6,2.7,3.0,3.1 -- MSVC 2008 (9.0)
Note these are only for the official python.org builds. Each version can also
be built using other MSVC versions. To
Changes by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<http://bugs.python.org/issue10217>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<http://bugs.python.org/issue11921>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Jeremy Kloth :
The newly implemented statically allocated Unicode objects do not clear their
cached representations (wstr and utf-8) at exit causing leaked blocks at exit
(see also issue46857).
At issue are the Unicode objects created by deepfreeze and the 1-character
Change by Jeremy Kloth :
--
keywords: +patch
nosy: +jkloth
nosy_count: 7.0 -> 8.0
pull_requests: +30121
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/32032
___
Python tracker
<https://bugs.python.org/i
Change by Jeremy Kloth :
--
pull_requests: -30121
___
Python tracker
<https://bugs.python.org/issue46084>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
keywords: +patch
pull_requests: +30122
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/32032
___
Python tracker
<https://bugs.python.org/issu
Change by Jeremy Kloth :
--
pull_requests: +30123
pull_request: https://github.com/python/cpython/pull/32032
___
Python tracker
<https://bugs.python.org/issue46
Change by Jeremy Kloth :
--
pull_requests: -30123
___
Python tracker
<https://bugs.python.org/issue46084>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
OK, I know it has been a busy month for Python, but this issue is really
hampering my bug fixing efforts. It makes the complete regrtest useless for
me. I am required to run each affected test directly so it is possible to miss
side-effects of changes made
New submission from Jeremy Kloth :
Testing on Windows occasionally has issues in test_compileall when running with
multiple processes. This is due to other test files importing stdlib modules
at the same time that compileall is doing its own testing. While not fatal
(test_compileall
Change by Jeremy Kloth :
--
keywords: +patch
pull_requests: +30127
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/32037
___
Python tracker
<https://bugs.python.org/issu
Jeremy Kloth added the comment:
With 3.8 so close to security only, I would doubt it is worth it anymore. I've
just run the PR against HEAD and it still works as is, so should be good to go.
--
versions: -Python 3.8
___
Python tracker
&
Change by Jeremy Kloth :
--
pull_requests: +30139
pull_request: https://github.com/python/cpython/pull/32050
___
Python tracker
<https://bugs.python.org/issue44
Jeremy Kloth added the comment:
Backports state that they are ready... I'm just a little uneasy as I've never
used cherry_picker before. 3.10 went smooth, but 3.9 required manual merging.
--
___
Python tracker
<https://bu
Change by Jeremy Kloth :
--
pull_requests: +30146
pull_request: https://github.com/python/cpython/pull/32048
___
Python tracker
<https://bugs.python.org/issue44
Change by Jeremy Kloth :
--
keywords: +patch
pull_requests: +30167
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/32079
___
Python tracker
<https://bugs.python.org/issu
Change by Jeremy Kloth :
--
pull_requests: +30168
pull_request: https://github.com/python/cpython/pull/32081
___
Python tracker
<https://bugs.python.org/issue46
New submission from Jeremy Kloth :
The string building and comparing of ast.dump() causes significant slowdowns on
the large ASTs produced when doing the roundtrip test on the stdlib.
This PR avoids that cost by doing a direct node traversal and comparison. It
results in a 33% runtime
Change by Jeremy Kloth :
--
keywords: +patch
pull_requests: +30212
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/32132
___
Python tracker
<https://bugs.python.org/issu
Change by Jeremy Kloth :
--
nosy: +vstinner
type: -> performance
___
Python tracker
<https://bugs.python.org/issue47131>
___
___
Python-bugs-list mai
Change by Jeremy Kloth :
--
nosy: +vstinner
___
Python tracker
<https://bugs.python.org/issue47089>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
pull_requests: +30311
pull_request: https://github.com/python/cpython/pull/32240
___
Python tracker
<https://bugs.python.org/issue47
Jeremy Kloth added the comment:
bpo-47089 is a duplicate of this issue and is fixed. This issue should be
closed as well.
--
___
Python tracker
<https://bugs.python.org/issue37
Jeremy Kloth added the comment:
This error will occur when there is a 64-bit/32-bit conflict. Normally, Python
extension modules are installed in architecture dependent locations, however
user-installed modules (pip install) can share a path referred to as "user
site".
A quick
Jeremy Kloth added the comment:
Well, to really see where things are going wrong, there is always the verbose
option when launching Python:
py -v -c "import binascii"
This will output a lot of information but should help pin down what is exactly
being imported when the error o
Jeremy Kloth added the comment:
Resolved with merged PR.
--
resolution: -> fixed
___
Python tracker
<https://bugs.python.org/issue47131>
___
___
Python-
Change by Jeremy Kloth :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue47131>
___
___
Pyth
Change by Jeremy Kloth :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue45354>
___
___
Python-bugs-list
New submission from Jeremy Kloth :
The latest zlib (1.2.12) introduces 3 new compiler warnings. Now being an
external library, I do not think we generally patch them, so I propose to
simply silence the warnings for the offending file.
For reference, the problem comes from
Change by Jeremy Kloth :
--
keywords: +patch
pull_requests: +30393
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/32337
___
Python tracker
<https://bugs.python.org/issu
Change by Jeremy Kloth :
--
nosy: +jkloth
nosy_count: 3.0 -> 4.0
pull_requests: +30394
pull_request: https://github.com/python/cpython/pull/32338
___
Python tracker
<https://bugs.python.org/issu
Jeremy Kloth added the comment:
My PR-32338 further reduces the runtime of the test another ~25%.
On my machine, before 85s, after 65s.
--
___
Python tracker
<https://bugs.python.org/issue46
Jeremy Kloth added the comment:
It seems so, as the zlib update was also backported to 3.9 and 3.10.
--
___
Python tracker
<https://bugs.python.org/issue47
Change by Jeremy Kloth :
--
pull_requests: +30399
pull_request: https://github.com/python/cpython/pull/32346
___
Python tracker
<https://bugs.python.org/issue47
Change by Jeremy Kloth :
--
pull_requests: +30400
pull_request: https://github.com/python/cpython/pull/32347
___
Python tracker
<https://bugs.python.org/issue47
Change by Jeremy Kloth :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Jeremy Kloth :
--
pull_requests: +30420
pull_request: https://github.com/python/cpython/pull/32382
___
Python tracker
<https://bugs.python.org/issue46
Jeremy Kloth added the comment:
It seems that an issue still exists.
https://buildbot.python.org/all/#/builders/130/builds/1050
has been running for nearly 9 hours at this point. I can leave it "stuck" if
there is some diagnostics that would be beneficial. But I would prefer no
Jeremy Kloth added the comment:
> Can you check the process hierarchy? I would like to know how many worker
> processes are still running under the main regrtest process. I expect to see
> exactly one. I don't know how to investigate more on such issue on Windows.
Ther
Jeremy Kloth added the comment:
Additional logging on failures is always welcome. Might I suggest that, in
this case, regrtest treats this action as a hard fail so as to not got lost in
the other transient failures (test_asyncio).
By that I mean, either to not re-run, or to still be
Jeremy Kloth added the comment:
I happened to catch a stuck build prior to the process being killed:
https://buildbot.python.org/all/#/builders//builds/2887
In short, the PR doesn't change the problem. The regrtest main will wait
indefinitely on the successfully killed process.
I
Jeremy Kloth added the comment:
Well, the kill timeout doesn't seem to be working, at least completely:
https://buildbot.python.org/all/#/builders/40/builds/3012
The worker process has been killed (line 562), but regrtest is still wa
Jeremy Kloth added the comment:
Another day, another stuck test_concurrent_futures...
https://buildbot.python.org/all/#/builders/40/builds/3030
The test process is again killed (line 568) but the processes from the
multiprocess pool are still alive. Once I manually kill those pool
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue38207>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
> Windows 7 is not supported for Python 3.9, so this buildbot can be
> disabled/upgraded.
As long as 3.7 and 3.8 are being tested through the buildbots, I would think
testing on Windows 7 is still advised.
That said, once those versions are no longer
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue36732>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue38544>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
While not getting into the error itself, there seems to be another issue in
that the logging that should be happening when the deletion routines from
test.support fail:
https://github.com/python/cpython/blob/5bc6a7c06eda20ba131ecba6752be0506d310181/Lib/test
Jeremy Kloth added the comment:
That covers the logging in _force_run(), but the warning.warn() line is also
not output, suggesting that the RuntimeWarning is being suppressed somewhere.
--
___
Python tracker
<https://bugs.python.org/issue38
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue43538>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue37945>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue2889>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
Adding windows team to the nosy list
--
components: +Windows
nosy: +jkloth, paul.moore, steve.dower, tim.golden, zach.ware
___
Python tracker
<https://bugs.python.org/issue40
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue44214>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Jeremy Kloth :
Currently, a stack overflow is causing the debug build Windows buildbots to
abort (bpo-11105). Once the regrtest process is terminated, the buildbot test
process hangs indefinitely waiting for handles to be closed (see msg350191 from
bpo-37531 for some
Change by Jeremy Kloth :
--
keywords: +patch
pull_requests: +25166
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26578
___
Python tracker
<https://bugs.python.org/issu
Jeremy Kloth added the comment:
To verify the PR, can someone please add the test-with-buildbots label on GH?
--
___
Python tracker
<https://bugs.python.org/issue44
Jeremy Kloth added the comment:
The PR has been successfully run on the buildbots.
Before:
https://buildbot.python.org/all/#/builders/593/builds/58
After:
https://buildbot.python.org/all/#/builders/593/builds/59
With these changes, at least now aborted runs can be seen as direct failures of
Change by Jeremy Kloth :
--
nosy: +jkloth
nosy_count: 11.0 -> 12.0
pull_requests: +25186
pull_request: https://github.com/python/cpython/pull/26578
___
Python tracker
<https://bugs.python.org/issu
Jeremy Kloth added the comment:
While now not as immediately beneficial, I believe that the linked PR would be
good for the long run. The ramifications of bpo-11105 meant that the Windows
buildbots were basically unusable for 5 days.
Realistically, any commit that triggers aborts in the
Jeremy Kloth added the comment:
There is a list `python-buildb...@python.org` that all buildbot owners have
been subscribed.
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue44
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue44779>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
Except that the output in question is not for manpages but for the
command-line. The analogous would be for `grep --help` (again an excerpt):
Context control:
-B, --before-context=NUM print NUM lines of leading context
-A, --after-context=NUM print NUM
New submission from Jeremy Kloth :
It appears there have been some console related changes in Windows 11
==
ERROR: test_open_name (test.test_winconsoleio.WindowsConsoleIOTests
Jeremy Kloth added the comment:
Note that I have a pending PR for adding a Windows 11 build worker that will,
once merged, help in testing a solution.
--
___
Python tracker
<https://bugs.python.org/issue45
Change by Jeremy Kloth :
--
keywords: +patch
pull_requests: +27062
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/28712
___
Python tracker
<https://bugs.python.org/issu
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue45806>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
I'll note that it also fails on first run on the Windows 11 builder:
https://buildbot.python.org/all/#/builders/737/builds/65
--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
___
P
Jeremy Kloth added the comment:
As noted on the PR landing page, this PR has caused failures of 2 buildbots:
https://buildbot.python.org/all/#builders/81/builds/272
https://buildbot.python.org/all/#builders/150/builds/227
(both are Windows 7)
--
nosy: +jkloth
Jeremy Kloth added the comment:
Would it not suffice to just make the singletons "immortal"?
Without affecting the hotpaths that are Py_INCREF and Py_DECREF, changing
_Py_Dealloc to test for objects with a "special" destructor could be used:
destructor dealloc = Py_
Jeremy Kloth added the comment:
> The problem is to make Py_INCREF/Py_DECREF efficient.
That is exactly why I didn't propose a change to them. The singletons
still are refcounted as usual, just that their ob_refcnt is ignored.
If they somehow reach 0, they just "resurrect&qu
Jeremy Kloth added the comment:
+1, obviously, as I came to the same conclusion above (see msg361122)
--
___
Python tracker
<https://bugs.python.org/issue39
1 - 100 of 394 matches
Mail list logo
