Jeremy Kloth added the comment:
OK, testing with the 7.1 SDK installed changes the crashes around, but
something is really amiss. I'd like to do more testing, but it will need to
wait until morning here.
--
___
Python tracker <
Jeremy Kloth added the comment:
On my VM, ssltests pass, but both the Perl and non-Perl segfault in
test_ssl (and many others). My VM has just VS2008 installed, does
VS2010 come with an updated SDK?
--
___
Python tracker <rep...@bugs.python.
Jeremy Kloth added the comment:
Submitted PR-1805 that should restore perl-less building.
Also some open issues as noted in the PR.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Jeremy Kloth <jeremy.kloth+python-trac...@gmail.com>:
--
pull_requests: +1888
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Jeremy Kloth:
Attempting to append to an existing file fails with no error set:
>>> import os, tempfile
>>> fd, fn = tempfile.mkstemp()
>>> os.write(fd, 'some text')
9
>>> os.close(fd)
>>> with open(fn, 'r+') as f:
... f.read(
Changes by Jeremy Kloth <jeremy.kloth+python-trac...@gmail.com>:
--
nosy: +jkloth
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Jeremy Kloth added the comment:
That's the real problem, I'm not *sure* it's the memory, but it does have the
symptoms. And that is why my buildbot was down earlier, I was attempting to
determine the bad stick and replace it. I'm just hoping I changed the right
one. That is why I brought
Jeremy Kloth added the comment:
My thinking is that in normal running, the in-use memory is below the bad bit.
It is due to that test using such a large chunk of memory that it pushes the
data into the bad area. I would wager that if largemem tests were run, the
would error as well
Jeremy Kloth added the comment:
Watch this space, but I'm pretty sure that it is (was) bad memory. It passes
memtest86+ but I had issues with these kits in other machines. I swapped out
the stick I believe that had the stuck bit.
Unfortunately, it is a wait and see solution, as they do
Changes by Jeremy Kloth <jeremy.kloth+python-trac...@gmail.com>:
--
nosy: +jkloth
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Jeremy Kloth added the comment:
> Wait? Why not suggesting to use this recent VS 2015 if it's
> supported?
In theory it is supported, yes. However, it is not compatible with previous C
runtimes. Meaning things like memory allocation (malloc) and file pointers
(FILE *) wouldn't pla
Jeremy Kloth added the comment:
Now that my buildbot is back online, there is one unresolved issue pertaining
to using VS9.0 only for building. That is building without Perl. It was a
supported feature prior to backporting the MSBuild toolchain. With recent
OpenSSL releases, without Perl
Jeremy Kloth added the comment:
All builders have been reset and pass, with the exception of the VS9 one which
is a different problem.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Jeremy Kloth added the comment:
A few things...
First to Victor's comments on the devguide. The following sentence after the
one quoted states:
"To use the build files in the PCbuild directory you will also need Visual
Studio 2010"
In short, you need *both* VS2008 and VS2010
Jeremy Kloth added the comment:
See http://bugs.python.org/issue15526
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30334>
___
__
Changes by Jeremy Kloth <jeremy.kloth+python-trac...@gmail.com>:
--
nosy: +jkloth
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Jeremy Kloth added the comment:
Yeah, sorry, I was working (fighting ;) with the new GitHub workflow while you
updated the status.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Jeremy Kloth added the comment:
PR1515 addresses the issue from bpo-15366 (venv from Python compiled with
builddir != srcdir). It seems that the original fix from bpo-15366 no longer
worked. This addresses that.
--
___
Python tracker <
Jeremy Kloth added the comment:
The change to sysconfig *may* be a regression wrt bpo-15366.
I'm not in the position to be able to check this possibility, ATM, but it is
possible that other things have also changed since this was commited 5 years
ago.
--
nosy: +jkloth
Jeremy Kloth added the comment:
Looking at test.support, the only errors that I can see being ignored by
unlink() is FileNotFoundError and NotADirectoryError (line 399). The only bare
OSError except clause is on line 359, but for an lstat() call.
--
nosy: +jkloth
Jeremy Kloth added the comment:
Tests are now failing due to end-of-line (?) differences.
I did a quick reading of the devguide, but didn't see any mention of the
settings to be used for Git on Windows wrt core.autocrlf.
--
___
Python tracker <
Jeremy Kloth added the comment:
After ensuring that Git is available to the buildbot service, the initial
update fails due to the existing build directory containing the Mercurial
checkout.
After manually removing the contents of the build directories, the update task
successfully completes
Jeremy Kloth added the comment:
Steve's guess wrt the _pth file being the cause was spot on. The buildbot is
back on track with successful results.
--
nosy: +jkloth
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Jeremy Kloth added the comment:
This is a known bug when compiling 64-bit extension modules.
http://bugs.python.org/issue9709
http://bugs.python.org/issue16779
http://bugs.python.org/issue20166
--
nosy: +jkloth
___
Python tracker <
Changes by Jeremy Kloth <jeremy.kloth+python-trac...@gmail.com>:
--
nosy: +jkloth
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Jeremy Kloth <jeremy.kloth+python-trac...@gmail.com>:
--
nosy: +jkloth
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Jeremy Kloth added the comment:
IMHO, this is a documentation bug with PyObject_CallMethod. The change to its
documentation to differ from PyObject_CallFunction was changed back in 2004.
It should have been updated then to reflect the already well-entrenched
behavior of those 2 (at the time
Jeremy Kloth added the comment:
It seems that the updated UCRT debug runtime has indeed solved the issue.
I suggest that this issue remains open pending an update to the devguide for
required settings for installing VS2015 with the updated runtime (see
msg262672). I have no idea if the VC
Jeremy Kloth added the comment:
I'm fine with the tests for CreateFunction failing for an ImDisk virtual drive,
however something needs to be changed with the test to not remove the test
directory on tearDown().
Changing it to use a temporary directory to link against is a workaround
Jeremy Kloth added the comment:
After attempting to find the installer for ucrtbased.dll on my dev machine and
reading various blog posts on the Visual C++ Team Blog and hunting through
several KB articles, I've come across what I think is needed for an up-to-date
Universal CRT.
When
Jeremy Kloth added the comment:
To reproduce:
P:\python-default>PCBuild\amd64\python_d.exe
Python 3.6.0a0 (default:708beeb65026, Mar 30 2016, 08:50:27) [MSC v.1900 64 bit
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" f
Jeremy Kloth added the comment:
I would have responded sooner, but add me to the list of those not receiving
tracker notifications...
My buildbot is running Windows 7 with all updates (last checked 3/29) and
VS2015 Update 1.
ucrtbase: 10.0.10586.9 (11/19/2015)
ucrtbased
New submission from Jeremy Kloth:
The Win32JunctionTests class fails when the test suite is run on an ImDisk[1]_
virtual disk. The junctions are created successfully, however os.stat() fails
on them (winerror 123). os.lstat() does succeed.
I'm inclined to believe that this is a bug
Jeremy Kloth added the comment:
The lastest set of updates were installed on 1/28. Visual Studio does have
Update 1. I'm doing another round of updates now, although nothing related to
VC 2015 or Visual Studio, however.
--
___
Python tracker <
Jeremy Kloth added the comment:
>From the UCRT sources:
// Deadlock Avoidance: When a new thread is created in the process, we
// create a new PTD for the thread. The PTD initialization function is
// called under the loader lock. This initialization function will a
Jeremy Kloth added the comment:
Oh, yes. It even occasionally happens on 2.7. The oldest occurrence I can
dig up is May/June of 2013 (for 2.7).
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Jeremy Kloth:
My Windows BuildBot (http://buildbot.python.org/all/buildslaves/kloth-win64) is
hanging in calls to the CRT function setlocale() as determined by attaching to
the hung test process in Visual Studio.
This has been happening occasionally (every tenth+ build
Jeremy Kloth added the comment:
My buildbot updated to VS2015.1 successfully. test_distutils is passing again.
As to the bug title, it should mention the incorrect DLL version error, not the
/LTCG *warning*. That's what I get for just doing a quick scan of the comments
Changes by Jeremy Kloth <jeremy.kloth+python-trac...@gmail.com>:
--
nosy: +jkloth
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Jeremy Kloth added the comment:
Added review
--
nosy: +jkloth
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26201>
___
___
Pyth
Jeremy Kloth added the comment:
The system is a dedicated Quad CPU @2.66GHz with 8GB RAM and running the tests
on an SSD. I doubt it is the hardware.
Please note, it is the only 64-bit Windows buildbot AND the only multi-core
Windows buildbot. So it catches lots of things that most others
Changes by Jeremy Kloth <jeremy.kloth+python-trac...@gmail.com>:
--
nosy: +jkloth
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23472
___
___
Python
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23437
___
___
Python
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23154
___
___
Python
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22919
___
___
Python
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22895
___
___
Python
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22462
___
___
Python
Jeremy Kloth added the comment:
Ah, yes indeeed. Sorry for the noise as it was that my local repos were having
some syncing issues so I had out of date sources.
Marking as closed (fixed) and duplicate of issue17432.
--
resolution: - duplicate
status: open - closed
New submission from Jeremy Kloth:
When using any of the PyUnicode_* functions in an extension module compiled
with Py_LIMITED_API defined, the resulting module cannot be imported due to:
ImportError: DLL load failed: The specified procedure could not be found.
Upon investigation, the error
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22024
___
___
Python
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21907
___
___
Python
Jeremy Kloth added the comment:
I'm curious as to the issues that arose in getting 'build_tkinter.py'
to work within the Visual Studio IDE, as that is what I used to
develop the patches to start with. I would like to look over the new
changes, but will not have any time to do so until 3-15-2014
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20485
___
___
Python
Jeremy Kloth added the comment:
Issue #16779 has a patch that suppresses the warning for 64-bit builds that
would also fix #9709.
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20166
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20441
___
___
Python
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19320
___
___
Python
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20341
___
___
Python
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20326
___
___
Python
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20168
___
___
Python
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20139
___
___
Python
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20144
___
___
Python
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20101
___
___
Python
Jeremy Kloth added the comment:
The attached patch changes support.rmtree to use os.lstat() instead of the
builtin _isdir() to test for directory-ness of a path.
--
keywords: +patch
Added file: http://bugs.python.org/file32875/symlink.patch
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19638
___
___
Python
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19629
___
___
Python
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19143
___
___
Python
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18987
___
___
Python
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18902
___
___
Python
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17741
___
___
Python
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12641
___
___
Python
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 rep...@bugs.python.org
http://bugs.python.org/issue18396
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18491
___
___
Python
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
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, of course
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 jeremy.kloth+python-trac...@gmail.com:
--
components: +Build, Windows
type: - compile error
versions: +Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18407
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 rep...@bugs.python.org wrote:
STINNER Victor added the comment:
- AdditionalOptions/USECL:MS_OPTERON /GS
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 instead
Jeremy Kloth added the comment:
Ugh, sorry for the bad quoting (silly GMail).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18407
Jeremy Kloth added the comment:
Adding Victor Stinner as he has been quite active in fixing Windows 64-bit
issues.
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15792
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 reserve could
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 rep...@bugs.python.org
http://bugs.python.org/issue17206
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_inner
1.159
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 interaction
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_object
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:
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
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 rep
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 { } while
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18255
___
___
Python
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:
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 assignments
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18211
___
___
Python
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#Namespaces
Jeremy Kloth added the comment:
The build of OpenSSL was failing due to an incomplete external check-in of
OpenSSL (missing the cached assembler files).
Martin has since updated the external and I have refreshed the OpenSSL exports
on the buildbot. It is no longer failing to compile
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17846
___
___
Python
201 - 300 of 392 matches
Mail list logo
