Jeremy Kloth added the comment:
Thanks for your patience with this Charlie, but please try another run this
time without the strftime() and mbstowcs() calls. Honest, we are getting
closer!
--
___
Python tracker
<https://bugs.python.
Jeremy Kloth added the comment:
You can safely execute each line individually (omitting the aforementioned
count/value pairs) or depending on how the copy/paste is being done, just paste
the script into a text editor (notepad) and comment out those lines. Then
copy-paste that modified
Jeremy Kloth added the comment:
Here is another test, this time removing Python from the equation (mostly :)
import ctypes, struct
crt_locale = ctypes.CDLL('api-ms-win-crt-locale-l1-1-0', use_errno=True)
crt_time = ctypes.CDLL('api-ms-win-crt-time-l1-1-0', use_er
Jeremy Kloth added the comment:
Final test, this time, no Python what so ever. I've added a zip containing a
simple C program (source and .exe) that performs the same test.
The output should be similar to:
The current locale is now: C
The time zone is: 'Mountain Daylight
Jeremy Kloth added the comment:
Thanks again! I will have some more tests for you to try tomorrow as I am out
of time for today.
I'm currently of the belief that there is something Python is going to have to
do to work around an issue within the CRT, but more testing will prove
Jeremy Kloth added the comment:
I've added another test executable (issue36792-2.zip) which should bring some
insight into where things are going wrong. Please run and post the results.
--
Added file: https://bugs.python.org/file48324/issue36792-
Jeremy Kloth added the comment:
I have managed to setup a VM that can reproduce the error. Unfortunately, the
error (heap corruption) is coming from within the UCRT. Attempting to work
around that, I came across another error in the UCRT.
Due to these errors in all available UCRT versions
Jeremy Metz added the comment:
Don't understand how #6422 addresses this - would also like to see a more
convenient API for timing; at present CLI gives a nice formatted output, and
timeit.timeit gives just the raw timing in seconds.
Would be easy to implement by simply refactoring
Jeremy Metz added the comment:
More specifically, #6422 also mentions at least in part this functionality, but
the main focus there seems to be the autorange function.
Propose splitting these two by reopening this use.
--
___
Python tracker
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue31612>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue31611>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
Also prior conversation:
https://bugs.python.org/issue30263#msg296311
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue34
Jeremy Kloth added the comment:
Not that it matters all that much, but from a terminology standpoint, WMI !=
PDH != Performance Counters.
Performance counters (the objects, not the topic) are provided by DLLs
registered in the HKLM\SYSTEM\CurrentControlSet\Services key. Their data is
Jeremy Kloth added the comment:
Correct. Windows provides the building blocks for implementing getloadavg(),
but does not provide an interface that does the averaging. That is deferred to
a per application basis. The best that an application can do for that is to
use thread pools. You
Jeremy Kloth added the comment:
The RegisterWaitForSingleObject() function does use the thread pool API:
https://docs.microsoft.com/en-us/windows/desktop/ProcThread/thread-pool-api
However, PdhCollectQueryDataEx() also creates a user-space thread to handle its
work of setting the event
Jeremy Kloth added the comment:
Since my buildbot has been infected with this bug, I took some time to hunt it
out. It turns out that issue is caused by an internal import triggered by the
open() function (at least on Windows).
A recent change to the interpreter (commit 9e4994d) changed
Jeremy Kloth added the comment:
The existing re-code solution is being triggered, as the `errors` in this case
is 'surrogateescape' with an encoding of 'cp1252'.
Here, pip is using subprocess.Popen() to have Python run setup.py. During
execution, a filename, 't
New submission from Jeremy Kloth :
When running Python via subprocess with captured output an encoding error
occurs attempting to output a Unicode filename. The same does not happen when
just using spawnl().
Python 3.6.5 (v3.6.5:f59c0932b4, Mar 28 2018, 17:00:18) [MSC v.1900 64 bit
(AMD64
Jeremy Kloth added the comment:
Related to issue34421
--
___
Python tracker
<https://bugs.python.org/issue34618>
___
___
Python-bugs-list mailing list
Unsub
Jeremy Kloth added the comment:
For pip, in call_subprocess() (given here in rough pseudo-code)
is_python = (cmd[0] == sys.executable)
kwds = {}
if is_python:
env['PYTHONIOENCODING'] = 'utf8'
kwds['encoding'] = 'utf8'
proc = Popen(..., **kwds
Jeremy Kloth added the comment:
Did you attempt to use the 3-line change I posted earlier? I stepped through
to test line-by-line to find the offending piece of code. And it was indeed
the open() call causing the test-tree to be processed prior to it being
completed. Thus making the .py
Jeremy Kloth added the comment:
This is also an issue on Windows when the target path resides within a
junction, paths outside of a junction respond (err, fail) as expected.
https://developercommunity.visualstudio.com/content/problem/272379/createfile-non-error-on-filename-with-trailing
New submission from Jeremy McMillan :
ipaddress module has no support for scoped IPv6 addresses which prevents the
use of ipaddress.ip_address() and ipaddress.IPv6Address() with (always
available by default on IPv6 systems) RFC conforming IPv6 link local addresses
that specify interface
Jeremy McMillan added the comment:
subclass workaround implementation example
https://github.com/isbm/salt/blob/976fe19d73ca6bf5df375eaa15d77ce4a5a54b7a/salt/_compat.py#L125
--
___
Python tracker
<https://bugs.python.org/issue34
New submission from Jeremy Kloth :
Since the KillPython target has been rewritten as an InlineTask, it can no
longer detect 64-bit processes due to MSBuild being 32-bit.
This leads to stuck buildbot runs:
https://buildbot.python.org/all/#/builders/17/builds/348
A few solutions that I can
Jeremy Kloth added the comment:
My testing shows differently:
D:\Public\Devel\cpython\master\PCbuild>set MSBUILD="C:\Program Files
(x86)\MSBuild\14.0\Bin\amd64\MSBuild.exe"
D:\Public\Devel\cpython\master\PCbuild>build -k -v -t foo
Using py -3.6 (found 3.6 with py.exe)
F
Jeremy Kloth added the comment:
Alternatively, to test for yourself:
1) build a 64-bit python:
> build -e -d -k -v -p x64
2) start the newly built interpreter:
> amd64\python_d.exe
3) in a different command prompt (using dummy target to just do the KillPython)
> build
Change by Jeremy Kloth :
--
keywords: +patch
pull_requests: +9263
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34980>
___
___
Py
Jeremy Kloth added the comment:
It seems my buildbot has a stuck process again.
The "sticking" occurred in this case due to test_concurrent_futures being hung
(for over 38hrs! which is a different issue) and a DSL link reset at the same
time.
So now, all builds on the master b
Jeremy Kloth added the comment:
The changed succeeded in killing the actively stuck process, so I say its all
good! Thanks for the merge.
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracke
Jeremy Kloth added the comment:
This really is not a bug, but more of a (common) misunderstanding of how the
mixing of namespace-aware (createElementNS) and namespace-ignorant
(createElement) methods work.
>From DOM3 Core
>[http://www.w3.org/TR/DOM-Level-3-Core/core.html#Name
Changes by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<http://bugs.python.org/issue18211>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Jeremy Gray:
The behavior of os.path.abspath differs between Mac OS X and Windows. It seems
like a bug that, on Windows, abspath strips trailing whitespace:
Windows:
>>> from os.path import abspath
>>> abspath('start ') + 'E
Jeremy Gray added the comment:
Maybe this a documentation / run-time warning issue, rather than bug. Trailing
spaces in filenames are illegal in Win32; nonetheless they can occur, because
there are instructions on how to remove such files:
http://support.microsoft.com/kb/320081. So
Jeremy Kloth added the comment:
Indeed, after debugging, it is a stack overflow caused by the introduction of
the different temporary variables in the Py_XINCREF, Py_XDECREF, and Py_DECREF
macros.
I've attached an updated patch that reuses the _py_tmp variable for those
temporary assign
Changes by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<http://bugs.python.org/issue18255>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
It seems that the changes committed by Ezio are causing the AMD64 Windows
buildbot to hang in test_ttk_guionly.
A note that this buildbot is running as a service so no desktop is available.
The same test however is working (skipped successfully) on the 3.3
Jeremy Kloth added the comment:
(Note that the buildbot is 64-bit so the paths need to be tcltk64)
The test_ttk_guionly passed successfully *from the command-line*. It is
currently hung in that test from the buildbot scheduler *as a service*.
I do not know of a simple way to test changes via
Jeremy Kloth added the comment:
At least in a debug build, the MSVC 64-bit compiler seems to allocate space for
each unique variable declared in the function body. Therefore, by changing the
temporary variables to be named identically, the amount of required space is
minimized.
The
Jeremy Kloth added the comment:
Except, in this case, it actually crashes the interpreter. I would hope to
think that it isn't common practice to just hide crashers especially when there
is a fix available.
--
___
Python tracker
Jeremy Kloth added the comment:
FYI, however, the new macro is designed as an internal implementation detail
along the lines of the other _Py_* macros. That is, just a tiny piece of a
larger function to be used at your own risk.
Either way, I've uploaded another version with the do { }
Jeremy Kloth added the comment:
Although the solution for test_ttk_guionly of disabling the gui resource is a
good quick fix, I'm curious as to why there isn't the same issue (test hangs)
when run using 3.3 on the same machine.
Note that by running as a service without desktop i
Jeremy Kloth added the comment:
I'm unsure as to how to get a stack trace from Visual Studio, but I can assure
you that the changes introduced by the change aff41a6421c2 *is* the cause of
the failure in test_marshal.
In a nutshell, the overflow happens in a recursion on the marhsal.c:r_o
Jeremy Kloth added the comment:
Here are some results after a detailed investigation:
- in debug, each variable declaration in a block is allocated on the stack
- in debug, r_object() uses 1416 bytes of stack
- in release, r_object() uses 512 bytes of stack
- default stack size is 1MB
- stack
Jeremy Kloth added the comment:
Here is some additional analysis of recursive functions in the 'pythoncore'
MSVC project:
Ratio Release Debug Filename:Function Name
StackStack
---
1.000 32 32_sre.asm:_validate_in
Jeremy Kloth added the comment:
The /STACK:reserve[,commit] linker option uses 'reserve' as the upper limit of
bytes to allow the executable to allocate. The optional 'commit' value
(default of 4096) is the amount of physical memory allocated as needed.
Therefore the
Jeremy Kloth added the comment:
I forgot to note that with the increased stack reserve my previous patches to
Py_DECREF() and related macros are no longer needed.
--
___
Python tracker
<http://bugs.python.org/issue17
Jeremy Kloth added the comment:
Adding Victor Stinner as he has been quite active in fixing Windows 64-bit
issues.
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue15
Jeremy Kloth added the comment:
This error is reproducible by simply passing '-j' to regrtest on any Windows
build so it is not Win64-specific.
It seems that when run in a subprocess, certain signals have C handlers that
cause the return value of getsignal() to return None which,
New submission from Jeremy Kloth:
The attached patch fixes compiler warnings for the pythoncore project when
building on 64-bit Windows.
Fixes for built-in modules are not included, however.
--
files: issue18407.diff
keywords: patch
messages: 192686
nosy: brian.curtin
Changes by Jeremy Kloth :
--
components: +Build, Windows
type: -> compile error
versions: +Python 3.4
___
Python tracker
<http://bugs.python.org/issu
Jeremy Kloth added the comment:
Yeah, sorry. This made it in by mistake. It was in the tree just to
eliminate warning noise.
On Mon, Jul 8, 2013 at 1:20 PM, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> - /USECL:MS_OPTERON /GS-
> %(AdditionalOptions)
Jeremy Kloth added the comment:
The change in grammar.c:addlabel() is correct. The return value is an
index into the ll->ll_label array, thus an int. The code could be
rewritten to avoid the pointer addition by saving the value of
ll->ll_nlabels before it is incremented and return that i
Jeremy Kloth added the comment:
Ugh, sorry for the bad quoting (silly GMail).
--
___
Python tracker
<http://bugs.python.org/issue18407>
___
___
Python-bugs-list m
Jeremy Kloth added the comment:
Just to note that, as it stands, these wrongly assigned options account for 28
of the 216 warnings (or 13%) currently emitted. This is just one easy step
towards a warning-free 64-bit Windows build.
It would be nice to get Win64 to be one of the warning-free
Jeremy Kloth added the comment:
Added new patch that removes the duplicate changes from issue #15792 and
comments the lone explicit cast.
These changes fix 116 of the 216 warnings (54%!) for Win64. Together with
issue #15792 brings the remaining count to 72.
I am unsure if splitting the
Changes by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<http://bugs.python.org/issue18491>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
It do not think that it is a just a Windows issue wrt faulthandler. It is that
there are no similar tests for signals on other platforms.
getsignal() needs to return *something* for the value of a handler which is not
SIG_DFL or SIG_IGN
Jeremy Kloth added the comment:
Added nosy list from issue 18523
--
nosy: +brian.curtin, larry, pitrou
___
Python tracker
<http://bugs.python.org/issue18
Changes by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<http://bugs.python.org/issue12641>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<http://bugs.python.org/issue17741>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<http://bugs.python.org/issue18902>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<http://bugs.python.org/issue18987>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Jeremy Kloth :
The comment regarding a Perl installation not being required is no longer true
with regards to OpenSSL 1.0+ (at least 1.0.0j and 1.0.1c). A Perl script(s) is
used to generate source files within the generated Makefiles.
I would suggest to remove the
Jeremy Kloth added the comment:
I would suggest trying to build OpenSSL (build_ssl.py) *without* Perl
installed. On Windows (7,64-bit at least) a dialog box pops up many
times asking which program to use to run XXX.pl.
This is using the externals from svn.python.org.
--
nosy
New submission from Jeremy Gillick :
The cookie library doesn't seem to support the standard date format (RFC 822)
for the expire property while parsing a cookie.
For example, in the Python prompt:
>>> import Cookie
>>> cookie = Cookie.SimpleCookie('bcooki
Jeremy Gillick added the comment:
I'm using Python 2.6.1
--
___
Python tracker
<http://bugs.python.org/issue15080>
___
___
Python-bugs-list mailing list
New submission from Jeremy Kloth :
The buildbot scripts do not work for the 64-bit targets.
Firstly, the "/p:UseEnv=True" parameter to msbuild causes the 32-bit only
projects (make_buildinfo and make_versioninfo) to fail due to architecture
mismatch. The scripts now uncondition
Jeremy Kloth added the comment:
In addition to the fixes from issue15102, the only way I could get the ssl
project to build successfully was to add the Perl installation (C:\Perl\bin) to
my PATH.
--
___
Python tracker
<http://bugs.python.
Jeremy Kloth added the comment:
Should I then open another issue just to track that bug? Have you
even tried using build_ssl.py *without* Perl? The changes required to
get that to work seem fairly extensive.
--
___
Python tracker
<h
Jeremy Kloth added the comment:
OK, I have discovered my issue(s) building OpenSSL. When I first downloaded
the openssl-1.0.1c external, the timestamps for the .asm files ended up being
older than their corresponding .pl sources therefore triggering the rules in
the makefile.
I then
Jeremy Kloth added the comment:
I forgot to add that with the patch the comment wrt Perl is truly correct.
--
___
Python tracker
<http://bugs.python.org/issue15
Jeremy Kloth added the comment:
The unrelated changes do seem to be an issue with the diff generated by Rietveld
--
nosy: +jeremy.kloth
___
Python tracker
<http://bugs.python.org/issue15
Jeremy Kloth added the comment:
On Mon, Jun 18, 2012 at 3:27 PM, Antoine Pitrou wrote:
> If I understand, the proposed changes are the following:
> https://bitbucket.org/jkloth/cpython-buildbot-amd64/changeset/2a20cee18add
That seems to be correct, yes.
> I'm not a Windows s
Jeremy Kloth added the comment:
Now that my buildbot is up and building (and failing at that) could these
changes be committed? It would get the buildbot to at least start testing
changes to Python proper.
--
___
Python tracker
<h
Changes by Jeremy Kloth :
Added file: http://bugs.python.org/file26095/5924b376d15f.diff
___
Python tracker
<http://bugs.python.org/issue15102>
___
___
Python-bugs-list m
Jeremy Kloth added the comment:
> The patch, as it stands, is clearly incorrect (as has been reviewed and
> acknowledged).
The most recent patch is correct.
> As for the changes to project files and the solution file: none of these
> changes should be necessary at all, unless i
Jeremy Kloth added the comment:
> As for the changes to project files and the solution file: none of these
> changes should be necessary at all, unless it's actually the case that the
> AMD64-Debug build doesn't work (i.e. neither in the buildbot, nor from the
> solu
Jeremy Kloth added the comment:
> I can believe that there are issues with the batch files. That's why I propose
> to look at one issue at a time (but it's not my priority at the moment).
That would mean that you do not care that the buildbots are failing.
That is exactly the
Jeremy Kloth added the comment:
> Hmm, obviously Perl *is* found. That leaves nasm.
nasm.exe was installed for myself (hence testing worked). I've now
made it available to the buildbot account as well.
Note that I have Perl installed but *not* on my PATH (on purpose).
The patch sup
Jeremy Kloth added the comment:
The OpenSSL (64-bit build) does not pass its own tests, while the 32-bit build
from the same source works just fine.
Stefan, how did you get your 64-bit build to work?
--
___
Python tracker
<http://bugs.python.
Jeremy Kloth added the comment:
I've narrowed this down to a CPU capabilities issue with OpenSSL.
What CPU are you using? I have a Q9450 (Core2 Quad)
If I set OPENSSL_ia32cap to 0 the self tests work. I'm now off to
debug OpenSSL CPU
Jeremy Kloth added the comment:
Ok, the final verdict on this issue is that nasm is to blame. I had
nasm 2.09.02 installed. I upgraded it to version 2.10.01 and
magically OpenSSL started working.
>From the nasm changelog is seems that the added instruction sets in
2.10 are required
Jeremy Kloth added the comment:
I've changed the malware scanner to disable real-time protection and
have disabled scanning of the buildbot directories.
Note that I could reproduce intermittent failures when using '-j' of
regrtest, but with these changes they n
Jeremy Kloth added the comment:
I've now also turned off indexing for the Buildbot account (and
folders). Hopefully this is the last directory walking process
interfering with the tests.
--
___
Python tracker
<http://bugs.python.org/is
New submission from Jeremy Kloth :
The registry key HKEY_PERFORMANCE_DATA is not accessible for non-interactive
users (e.g., buildbot as a service).
The following patches skip the offending test when the tests unless the they
are run from an interactive session.
--
components: Tests
Changes by Jeremy Kloth :
Added file: http://bugs.python.org/file26369/winreg-3.x.diff
___
Python tracker
<http://bugs.python.org/issue15334>
___
___
Python-bugs-list m
Jeremy Kloth added the comment:
The buildbot service account is a standard user (per the buildbot
servce installation directions). When logged on, the user can access
the share. Just when logged on as a service is when it cannot.
After much searching, I still cannot find any information on
Changes by Jeremy Hylton :
--
nosy: +Jeremy.Hylton
___
Python tracker
<http://bugs.python.org/issue11549>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<http://bugs.python.org/issue15431>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Jeremy Kloth:
It would seem that enabling GCC's type conversion/truncation warnings would be
a good thing for Python builds.
This would bring GCC builds in line with MSVC builds and reduce the burden on
the Windows developers in fixing them. Also, it would bring atte
New submission from Jeremy Kloth:
Currently, removing directories during testing on Windows w/NTFS can causing
sporadic failures due to access denied errors. This is caused by other
processes getting a handle to the directory itself (change notifications) or a
handle to a file within the
Jeremy Kloth added the comment:
> This is a (near) duplicate of issue7443, I think.
Partially so it seems. However, my testing with Process Monitor (from
sysinterals) shows that most of the access denied errors occur when
removing directories.
The blind rename-remove dance doesn't w
Jeremy Kloth added the comment:
> I'm getting more than thousand warnings:
>
> $ CFLAGS="-Wconversion -Wno-sign-conversion" ./configure
> $ LC_ALL=C make -s -j8 2>&1 | tee log
> $ grep Wconversion log | wc -l
> 1163
My Win64 buildbot currentlyhas 544 con
Jeremy Kloth added the comment:
I must also add that the proposed solution works well within the test suite as
the access denied error can also occur when creating subsequent files, not just
removing them.
This solution eliminates the need to wrap all creation calls with access denied
Jeremy Kloth added the comment:
> Well, test_startfile seems to be a common issue on that buildbot.
I wouldn't really call it common (twice in the last 30 runs).
However I would wager that the PermissionError is being caused by an
unknown (without having Process Monitor running when t
Jeremy Kloth added the comment:
I have just completed an upgrade of the Win64 buildbot slave with a
faster hard drive and the issue is now much more pronounced.
--
___
Python tracker
<http://bugs.python.org/issue15
Jeremy Kloth added the comment:
> What are those programs exactly? A buildbot should ideally have a lean system
> install that does not interfere with the tests running.
My development machine has add'l programs, not the buildbot machine.
Sorry is there was any confusion. I g
Jeremy Kloth added the comment:
> Tim Golden added the comment:
> I'm tentative about using ctypes this just because I don't believe we use it
> anywhere else.
ctypes is already used later in test_support so I figured it was fine
to u
Jeremy Kloth added the comment:
> I wonder why it couldn't use os.listdir to find out whether the directory is
> empty, and os.stat to find out whether a specific file or directory still
> exists.
It is possible to do the same thing with just os.listdir. The use of
the Find*
301 - 400 of 577 matches
Mail list logo
