I created PR which fixes potential crash.
Serhiy Storchaka approved it already, but he wants one other
review from core dev. And I updated document after his review too.
So I want more one reviewer for the PR.
Someone help me?
For GC types, tp_dealloc should call PyObject_GC_UnTrack() before
calling any APIs which can run arbitrary code, including Py_DECREF.
Without calling it, GC may happen during tp_dealloc and GC will find
object which refcnt == 0.
I checked all GC types and find some unsafe tp_dealloc.
Even "extending and embedding" document missed untracking.
INADA Naoki <songofacandy(a)gmail.com>
Over in Ubuntu, we've gotten reports about some performance regressions in
Python 2.7 when moving from Trusty (14.04 LTS) to Xenial (16.04 LTS).
Trusty's version is based on 2.7.6 while Xenial's version is based on 2.7.12
with bits of .13 cherry picked.
We've not been able to identify any change in Python itself (or the
Debian/Ubuntu deltas) which could account for this, so the investigation has
led to various gcc compiler options and version differences. In particular
disabling LTO (link-time optimization) seems to have a positive impact, but
doesn't completely regain the loss.
Louis (Cc'd here) has done a ton of work to measure and analyze the problem,
but we've more or less hit a roadblock, so we're taking the issue public to
see if anybody on this mailing list has further ideas. A detailed analysis is
available in this Google doc:
The document should be public for comments and editing.
If you have any thoughts, or other lines of investigation you think are
worthwhile pursuing, please add your comments to the document.
I just pushed a change to Bedevere to help track what stage a pull request
is in. The stages are:
- awaiting review
- awaiting core review
- awaiting changes
- awaiting change review
- awaiting merge
The "review" stage is for when a pull request has no reviews either
approving or requesting changes (this only applies to PRs not by a core
dev; all PRs created by a core dev are flagged as awaiting merge
The "core review" stage is when a review has been done by one or more
non-core folk, but no core devs. The idea with the distinction is to
encourage people to help in doing initial reviewing of PRs who happen to
not be core devs since triaging issues and reviewing pull requests is the
biggest chunk of work in maintaining CPython.
The "changes" stage occurs when a core dev requests changes to a PR (a
non-core dev review will not trigger this). A comment will be left to this
effect with instructions for the PR creator to leave a comment saying "I
didn't expect the Spanish Inquisition" to signal when they believe they are
done addressing the reviewer's comments (there is also appropriate comments
to explain the quote along with an easter egg(s) :) .
The "change review" label means that the PR creator left the Spanish
Inquisition quote and so now the core dev(s) who requested changes should
re-review the PR. There will be a comment mentioning the core devs to this
effect so that they will get a proper GitHub notification and they can
check the label to see if the PR creator believes they are ready for
another round of review (compared to now where you have to hunt around in
the PR to see if it's ready for another review).
The "merge" label means the PR has received an approving review from a core
dev and so it should be ready to go.
Now when any state change happens to trigger these labels, any preexisting
"awaiting" label will be cleared and the new one set. But removing or
setting a label manually won't trigger an action, so in this instance you
can override Bedevere manually until some later event occurs which triggers
an automatic update.
One thing I do want to call out is that it's now more important that core
devs leave appropriate "approved" and "request changes" reviews through the
GitHub UI instead of just leaving a comment when they approve or want
changes to a PR, respectively. Not only is this necessary to automate this
part of the stage labeling, but it also visibly exposes in the GitHub UI
the review state of a PR.
I'm not backfilling the open PRs as it's more work and I don't want to do
said work. ;) But as PRs are opened, reviewed, etc., things should slowly
trickle their way through the various PRs.
I should mention this is the second-to-last "intrusive" workflow change I
have planned to introduce some new aspect to the workflow (the last one
being a status check for a news entry after every branch has been
blurbified). After these two changes land, everything else I have planned
is just touching things up (e.g. the CLA check becoming a status check
instead of a label, touching up CONTRIBUTING.md, etc.). I think some other
people have plans to improve things as well, but at least my TODO list of
"radical" changes to our workflow is almost done!
I was just informed from our hosting provider for bugs.python.org <http://bugs.python.org/>, Hetzner Online - that the server is currently being migrated to a new data center.
Unfortunately I was not informed ahead of time and working with the provider to better communicate and schedule future maintenance periods accordingly.
Apologies for any inconvenience this has caused. I will be posting status updates at https://status.python.org/ <https://status.python.org/>.
As many of you know, we are working to migrate this off the current hosting provider in the next 3 months.
Mark Mangoba | PSF IT Manager | Python Software Foundation | mmangoba(a)python.org | python.org | Infrastructure Staff: infrastructure-staff(a)python.org | GPG: 2DE4 D92B 739C 649B EBB8 CCF6 DC05 E024 5F4C A0D1
Just a heads-up, primarily for Marc-Andre, but letting everyone know for
Next time we need to renew the PSF code signing certificate used for
Windows releases, we will need to use a different CA.
Our current certificate is from StartCom, who are losing their status as
a trusted CA on Windows, which means any of their certificates issued
after the 26th of September this year will be treated as invalid:
The certificate we have right now is valid through February 2019, so
there's no urgency to change (unless we want to avoid the risk of
"accidental certificate revocation", which is one of the reasons
Microsoft has lost trust in StartCom). Because the revocation of the
root CA has a start date, all of our current releases and future
releases with the current certificate will be fine.
Since this will likely harm StartCom's business, it's very likely that
they will get their act together and by the time we come to renew
they'll be acceptable again. But we probably do want to be planning
ahead to switch CA regardless.
And for our macOS and Linux friends who may be uncertain what I'm
referring to: this is the certificate embedded in the installer and
every executable binary in our Windows distributions. It has nothing to
do with GPG or the signature files you can download from python.org
(these are still associated with my personal and completely unverified
key, which is fine since nobody on Windows actually cares about GPG :) ).
I'm working on Windows with Python 3.6. I'm trying to make a wWinMain() GUI
application that uses an embedded python interpreter. I'm having various
issues with being unable to load extension modules, but I won't go into that
now because I've tracked my issue down to a much simpler test case.
To begin, consider the source code of pythonw.exe:
/* Minimal main program -- everything is loaded from the library. */
int WINAPI wWinMain(
HINSTANCE hInstance, /* handle to current instance */
HINSTANCE hPrevInstance, /* handle to previous instance */
LPWSTR lpCmdLine, /* pointer to command line */
int nCmdShow /* show state of window */
return Py_Main(__argc, __wargv);
Now consider a simple python script, which I save in source.py
f = open('C:\\Users\\rutski\\Desktop\\hello.txt', 'w')
and run with
> pythonw.exe source.py
This produces the file `hello.txt` with the expected output. Now I create a
new Visual Studio solution. I make it Win32 project, choose "Windows
Application" and "Empty Project." I create a new source file main.c and I
copy-paste the source code of from pythonw (with Py_Main and all that). Now I
add the following settings:
C:\Users\rutski\Documents\python\PCbuild\amd64 --- Library Search Directory
C:\Users\rutski\Documents\python\Include --- Include Directory
C:\Users\rutski\Documents\python\PC --- Include
Directory (for pyconfig.h)
I choose "Debug | x64" and hit build. I pop open cmd.exe, browse to where
mything.exe is, and execute
> mything.exe source.py
But this time nothing happens. No hello.txt gets created. I get no crash
window or error message. I do not get thrown into a debugger. I just get no
result. Am I missing some build flags here or something?
I'm running the __exact__ same C code that pythonw.exe is, but mine isn't
working. What gives?
I can't even seem to get Py_Main() to execute some python code from within my
own application, so trying to write my own embed code is basically hopeless.
If anybody could shed any light on this it would be much appreciated!