[Python-Dev] Keeping an eye on Travis CI, AppVeyor and buildbots: revert on regression

2018-05-30 Thread Victor Stinner 
Hi,

I fixed a few tests which failed randomly. There are still a few, but
the most annoying have been fixed. I will continue to keep an eye on
our CIs: Travis CI, AppVeyor and buildbots. Sometimes, even when I
report a regression, the author doesn't fix the bug. But when a test
fails on Travis CI or AppVeyor, we cannot merge a pull request, so it
blocks our whole workflow.

I will restart the policy that I proposed last year: if a change
introduces a regression and I'm unable to fix it quickly (say in less
than 2 hours and the author isn't available), I will simply revert the
change. Please don't take it personally, the purpose is just to
unblock our workflow and be able to detect other regressions. It's
just an opportunity for the change author to fix the change without
the pressure of the broken CI.

Buildbots only send email notifications to [email protected]
when the state changes from success (green) to failure (red). It's
much simpler for me to spot a regression when most buildbots are
green.

By the way, while miss-lington is really an amazing tool (thanks
Mariatta!!!), most core developers (including me!) forgot that 2 years
ago, the policy was to check if a change doesn't break buildbots
before backporting a change (well, 2 years ago we forward-ported
changes, but it's the same idea ;-)). Please remind that we only run
tests on Linux and Windows as pre-commit checks on GitHub pull
requests, whereas it's very common to spot bugs on buildbots thanks to
the diversity of platforms and architectures (and different
performance).

All buildbot builders can be watched at:
http://buildbot.python.org/all/#/builders

But I prefer to watch notifications on IRC (#python-dev on Freenode)
and the buildbot-status mailing list.

https://mail.python.org/mm3/mailman3/lists/buildbot-status.python.org/

--

Night gathers, AND NOW MY WATCH BEGINS.
IT SHALL NOT END UNTIL MY DEATH.
I shall take no wife, hold no lands, father no children.
I shall wear no crowns and win no glory.
I shall live and die at my post.
I am the sword in the darkness.
I am the watcher on the walls.
I am the fire that burns against cold, the light that brings the dawn,
the horn that wakes the sleepers, the shield that guards the realms of
men.
I pledge my life and honor to the Night's Watch, for this night and
all the nights to come.

Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] How to watch buildbots?

2018-05-30 Thread Victor Stinner 
Hi,

I would like to delegate the maintenance task "watch buildbots", since
I'm already very busy with many other maintenance tasks. I'm looking
for volunteers to handle incoming emails on buildbot-status. I already
started to explain to Pablo Galindo Salgado how to do that, but it
would be great to have at least two people doing this task. Otherwise,
Pablo wouldn't be able to take holiday or just make a break for any
reason. Buildbots are evil beast which require care every day.
Otherwise, they quickly turn red and become less useful :-(

It seems like the first blocker issue is that we have no explicit
documentation "how to deal with buildbots?" (the devguide
documentation is incomplete, it doesn't explain what I'm explaining
below). Let me start with a few notes of how I watch buildbots.

I'm getting buildbot notifications on IRC (#python-dev on Freenode)
and on the buildbot-status mailing list:
https://mail.python.org/mm3/mailman3/lists/buildbot-status.python.org/

When a buildbot fails, I look at tests logs and I try to check if an
issue has already been reported. For example, search for the test
method in title (ex: "test_complex" for test_complex() method). If no
result, search using the test filename (ex: "test_os" for
Lib/test/test_os.py). If there is no result, repeat with full text
searchs ("All Text"). If you cannot find any open bug, create a new
one:

* The title should contain the test name, test method and the buildbot
name. Example: " test_posix: TestPosixSpawn fails on PPC64 Fedora
3.x".
* The description should contain the link to the buildbot failure. Try
to identify useful parts of tests log and copy them in the
description.
* Fill the Python version field (ex: "3.8" for 3.x buildbots)
* Select at least the "Tests" Component. You may select additional
Components depending on the bug.

If a bug was already open, you may add a comment to mention that there
is a new failure: add at least a link to buildbot name and a link to
the failure.

And that's all! Simple, isn't it? At this stage, there is no need to
investigate the test failure.

To finish, reply to the failure notification on the mailing list with
a very short email: add a link to the existing or the freshly created
issue, maybe copy one line of the failure and/or the issue title.

Recent bug example: https://bugs.python.org/issue33630

--

Later, you may want to analyze these failures, but I consider that
it's a different job (different "maintenance task"). If you don't feel
able to analyze the bug, you may try to find someone who knows more
than you about the failure.

For better bug reports, you can look at the [Changes] tab of a build
failure, and try to identify which recent change introduced the
regression. This task requires to follow recent commits, since
sometimes the failure is old, it's just that the test fails randomly
depending on network issues, system load, or anything else. Sometimes,
previous tests have side effects. Or the buildbot owner made a change
on the system. There are many different explanation, it's hard to
write a complete list. It's really on a case by case basis.

Hopefully, it's now more common that a buildbot failure is obvious and
caused by a very specific recent changes which can be found in the
[Changes] tab.

--

If you are interested to help me on watching our CIs: please come on
the [email protected] mailing list! Introduce yourself and
explain how do you plan to help. I may propose to mentor you to assist
you the first weeks.

As I wrote, maybe a first step would be to write down a documentation
how to deal with buildbots and/or update and complete existing
documentations.

https://devguide.python.org/buildbots/

Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Compact GC Header

2018-05-30 Thread Serhiy Storchaka 

29.05.18 17:15, Steve Dower пише:
Looks like it breaks the 3.7 ABI, which is certainly not allowed at this 
time. But it’s not a limited API structure, so no problem for 3.8.


Looks like it breaks only extensions that use private macros 
_PyObject_GC_TRACK, _PyObject_GC_UNTRACK and _PyObject_GC_IS_TRACKED. 
Those that use only public functions PyObject_GC_Track() and 
PyObject_GC_UnTrack() shouldn't be affected.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How to watch buildbots?

2018-05-30 Thread Ivan Pozdeev via Python-Dev 

On 30.05.2018 13:01, Victor Stinner wrote:

Hi,

I would like to delegate the maintenance task "watch buildbots", since
I'm already very busy with many other maintenance tasks. I'm looking
for volunteers to handle incoming emails on buildbot-status. I already
started to explain to Pablo Galindo Salgado how to do that, but it
would be great to have at least two people doing this task. Otherwise,
Pablo wouldn't be able to take holiday or just make a break for any
reason. Buildbots are evil beast which require care every day.
Otherwise, they quickly turn red and become less useful :-(

It seems like the first blocker issue is that we have no explicit
documentation "how to deal with buildbots?" (the devguide
documentation is incomplete, it doesn't explain what I'm explaining
below). Let me start with a few notes of how I watch buildbots.

I'm getting buildbot notifications on IRC (#python-dev on Freenode)
and on the buildbot-status mailing list:
https://mail.python.org/mm3/mailman3/lists/buildbot-status.python.org/

When a buildbot fails, I look at tests logs and I try to check if an
issue has already been reported. For example, search for the test
method in title (ex: "test_complex" for test_complex() method). If no
result, search using the test filename (ex: "test_os" for
Lib/test/test_os.py). If there is no result, repeat with full text
searchs ("All Text"). If you cannot find any open bug, create a new
one:

* The title should contain the test name, test method and the buildbot
name. Example: " test_posix: TestPosixSpawn fails on PPC64 Fedora
3.x".
* The description should contain the link to the buildbot failure. Try
to identify useful parts of tests log and copy them in the
description.
* Fill the Python version field (ex: "3.8" for 3.x buildbots)
* Select at least the "Tests" Component. You may select additional
Components depending on the bug.

If a bug was already open, you may add a comment to mention that there
is a new failure: add at least a link to buildbot name and a link to
the failure.

And that's all! Simple, isn't it? At this stage, there is no need to
investigate the test failure.

To finish, reply to the failure notification on the mailing list with
a very short email: add a link to the existing or the freshly created
issue, maybe copy one line of the failure and/or the issue title.

Recent bug example: https://bugs.python.org/issue33630

--

Later, you may want to analyze these failures, but I consider that
it's a different job (different "maintenance task"). If you don't feel
able to analyze the bug, you may try to find someone who knows more
than you about the failure.

For better bug reports, you can look at the [Changes] tab of a build
failure, and try to identify which recent change introduced the
regression. This task requires to follow recent commits, since
sometimes the failure is old, it's just that the test fails randomly
depending on network issues, system load, or anything else. Sometimes,
previous tests have side effects. Or the buildbot owner made a change
on the system. There are many different explanation, it's hard to
write a complete list. It's really on a case by case basis.

Hopefully, it's now more common that a buildbot failure is obvious and
caused by a very specific recent changes which can be found in the
[Changes] tab.

--

If you are interested to help me on watching our CIs: please come on
the [email protected] mailing list! Introduce yourself and
explain how do you plan to help. I may propose to mentor you to assist
you the first weeks.

As I wrote, maybe a first step would be to write down a documentation
how to deal with buildbots and/or update and complete existing
documentations.

https://devguide.python.org/buildbots/

Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru


What's the big idea of separate buildbots anyway? I thought the purpose 
of CI is to test everything _before_
it breaks the main codebase. Then it's the job of the contributor rather 
than maintainer to fix any breakages.


So, maybe making them be driven by Github checks would be a better time 
investment.
Especially since we've got VSTS checks just recently, so whoever was 
doing that still knows how to interface with this Github machinery.


If the bots cancel a previous build if a new one for the same PR 
arrives, this will not lead to a significant load difference 'cuz the 
number of
actively developed PRs is stable and roughly equal to the number of 
merges according to the open/closed tickets dynamics.


--
Regards,
Ivan

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Compact GC Header

2018-05-30 Thread Nick Coghlan 
On 30 May 2018 at 20:43, Serhiy Storchaka  wrote:

> 29.05.18 17:15, Steve Dower пише:
>
>> Looks like it breaks the 3.7 ABI, which is certainly not allowed at this
>> time. But it’s not a limited API structure, so no problem for 3.8.
>>
>
> Looks like it breaks only extensions that use private macros
> _PyObject_GC_TRACK, _PyObject_GC_UNTRACK and _PyObject_GC_IS_TRACKED. Those
> that use only public functions PyObject_GC_Track() and
> PyObject_GC_UnTrack() shouldn't be affected.


The ABI concern is with PyGC_Head changing size, as that's a public struct
definition in a public header - even though the macros for working with it
are marked as private, the struct itself isn't.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How to watch buildbots?

2018-05-30 Thread Nick Coghlan 
On 30 May 2018 at 22:30, Ivan Pozdeev via Python-Dev 
wrote:

> What's the big idea of separate buildbots anyway? I thought the purpose of
> CI is to test everything _before_
> it breaks the main codebase. Then it's the job of the contributor rather
> than maintainer to fix any breakages.
>

> So, maybe making them be driven by Github checks would be a better time
> investment.
> Especially since we've got VSTS checks just recently, so whoever was doing
> that still knows how to interface with this Github machinery.
>
> If the bots cancel a previous build if a new one for the same PR arrives,
> this will not lead to a significant load difference 'cuz the number of
> actively developed PRs is stable and roughly equal to the number of merges
> according to the open/closed tickets dynamics.
>

There are a few key details here:

1. We currently need to run post-merge CI anyway, as we're not doing
linearised commits (where core devs just approve a change without merging
it, and then a gating system like Zuul ensures that the tests are run
against the latest combination of the target branch and the PR before
merging the change)
2. Since the buildbots are running on donated dedicated machines (rather
than throwaway instances from a dynamic CI provider), we need to review the
code before we let it run on the contributed systems
3. The buildbot instances run *1* build at a time, which would lead to
major PR merging bottlenecks during sprints if we made them a gating
requirement
4. For the vast majority of PRs, the post-merge cross-platform testing is a
formality, since the code being modified is using lower level
cross-platform APIs elsewhere in the standard library, so if it works on
Windows, Linux, and Mac OS X, it will work everywhere Python runs
5. We generally don't *want* to burden new contributors with the task of
dealing with the less common (or harder to target) platforms outside the
big 3 - when they do break, it often takes a non-trivial amount of platform
knowledge to understand what's different about the platform in question

Cheers,
Nick.

P.S. That said, if VSTS or Travis were to offer FreeBSD as an option for
pre-merge CI, I'd suggest we enable it, at least in an advisory capacity -
it's a better check against Linux-specific assumptions creeping into the
code base than Mac OS X, since the latter is regularly different enough
from other *nix systems that we need to give it dedicated code paths.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How to watch buildbots?

2018-05-30 Thread Victor Stinner 
2018-05-30 14:30 GMT+02:00 Ivan Pozdeev via Python-Dev :
> What's the big idea of separate buildbots anyway? I thought the purpose of
> CI is to test everything _before_
> it breaks the main codebase. Then it's the job of the contributor rather
> than maintainer to fix any breakages.

I will answer more generally.

Technically, buildbots support to send emails to author of changes
which introduced a regression.

But a build may test a single change or dozens of new changes.

Moreover, our test suite is not perfect: they are at least 5 known
tests which fail randomly. Even if we fix these unstable tests, it's
also "common" that buildbots fail for "external" reasons:

* network failure: fail to clone the GitHub repository

* functional test using an external service and the service is down. I
started to list external services used by "unit" tests:
http://vstinner.readthedocs.io/cpython.html#services-used-by-unit-tests

* vacuum cleaner:
https://mail.python.org/pipermail/python-buildbots/2017-June/000122.html

* many other random reasons...

Since two years, I'm trying to fix all tests failing randomly, but as
I just explained, it's really hard to get a failure rate of 0%.

I'm not sure that we can "require" authors of pull requests to
understand buildbot failures...

So I prefer to keep the status quo: filter buildbot failures manually.

Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Withdraw PEP 546? Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2018-05-30 Thread Victor Stinner 
Hi,

tl; dr I will withdraw the PEP 546 in one week if noboy shows up to
finish the implementation.


Last year,I wrote the PEP 546 with Cory Benfield:
"Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7"
https://www.python.org/dev/peps/pep-0546/

The plan was to get a Python 2.7 implementation of Cory's PEP 543:
"A Unified TLS API for Python"
https://www.python.org/dev/peps/pep-0543/

Sadly, it seems like Cory is no longer available to work on the projec
(PEP 543 is still a draft)t.

The PEP 546 is implemented:
https://github.com/python/cpython/pull/2133

Well, I closed it, but you can still get it as a patch with:
https://patch-diff.githubusercontent.com/raw/python/cpython/pull/2133.patch

But tests fail on Travis CI whereas I'm unable to reproduce the issue
on my laptop (on Fedora). The failure seems to depend on the version
of OpenSSL. Christian Heimes has a "multissl" tool which automates
tests on multiple OpenSSL versions, but I failed to find time to try
this tool.

Time flies and one year later, the PR of the PEP 546 is still not
merged, tests are still failing.

One month ago, when 2.7.15 has been released, Benjamin Peterson,
Python 2.7 release manager, simply proposed:
"The lack of movement for a year makes me wonder if PEP 546 should be
moved to Withdrawn status."

Since again, I failed to find time to look at the test_ssl failure, I
plan to withdraw the PEP next week if nobody shows up :-( Sorry Python
2.7!

Does anyone would benefit of MemoryBIO in Python 2.7? Twisted,
asyncio, trio, urllib3, anyone else? If yes, who is volunteer to
finish the MemoryBIO backport (and maintain it)?

Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Withdraw PEP 546? Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2018-05-30 Thread Nathaniel Smith 
On Wed, May 30, 2018, 07:30 Victor Stinner  wrote:

> Does anyone would benefit of MemoryBIO in Python 2.7? Twisted,
> asyncio, trio, urllib3, anyone else?


Asyncio and trio are strongly py3-only. Twisted's TLS functionality is
built around pyopenssl, so the stdlib ssl module doesn't affect them.
Urllib3 uses the socket-wrapping APIs, not MemoryBIO. So fwiw I don't think
any of those projects would benefit.

-n
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Forward of moderated message

2018-05-30 Thread python-list-bounces 
--- Begin Message ---
Dear Windows developer,

I'm a program manager in the Partner App Experience Team at Microsoft. We're 
reaching out to notify you of a potential issue in one of your applications. 
This issue is automatically generated by Windows Error Reporting, a system 
which generates an error report whenever a crash happens on user's machine.

The issue details are below. Our goal is to work with you to address this issue 
and to understand what your expected timeline to address this issue might be. 
If you have any questions about the details below or have already addressed 
this issue in a forthcoming update, please let me know.
Issue

Appcrash in 
FAIL_FAST_FATAL_APP_EXIT_DETOURS_c409_python27.dll!PyMapping_HasKey

Product

Python

Module

python27.dll

Module Version

2.7.12150.1013

OS

Windows 10 Insider Preview, Windows 10

OS Version

17134, 16299, 15063, 14393

OS Architecture

x64, x86

Environment

Desktop

Occurrence

More than 0.1M hits in the last 14 days

Impacted Locations

US, Canada, Europe, Brazil

Triage Notes

PROCESS_NAME:  kodi.exe
ERROR_CODE: (NTSTATUS) 0xc409 - The system detected an overrun of a 
stack-based buffer in this application. This overrun could potentially allow a 
malicious user to gain control of this application.
EXCEPTION_CODE: (NTSTATUS) 0xc409 - The system detected an overrun of a 
stack-based buffer in this application. This overrun could potentially allow a 
malicious user to gain control of this application.

WATSON_BKT_PROCVER:  17.6.0.0
WATSON_BKT_MODULE:  ucrtbase.dll
WATSON_BKT_MODVER:  10.0.17134.1

PROBLEM_CLASSES:

ID: [0n278]
Type:   [FAIL_FAST]
Class:  Primary
Scope:  DEFAULT_BUCKET_ID (Failure Bucket ID prefix)
BUCKET_ID
Name:   Add
Data:   Omit
PID:[Unspecified]
TID:[Unspecified]
Frame:  [0]

ID: [0n267]
Type:   [FATAL_APP_EXIT]
Class:  Addendum
Scope:  DEFAULT_BUCKET_ID (Failure Bucket ID prefix)
BUCKET_ID
Name:   Add
Data:   Omit
PID:[Unspecified]
TID:[Unspecified]
Frame:  [0]

ID: [0n138]
Type:   [DETOURS]
Class:  Addendum
Scope:  DEFAULT_BUCKET_ID (Failure Bucket ID prefix)
BUCKET_ID
Name:   Add
Data:   Omit
PID:[0x3308]
TID:[0x2548]
Frame:  [0] : ucrtbase!abort

BUGCHECK_STR:  FAIL_FAST_FATAL_APP_EXIT_DETOURS

STACK_TEXT:
0dd3db08 56e74b1b 00650063 00610076 003a006c ucrtbase!abort+0x4b
WARNING: Stack unwind information not available. Following frames may be wrong.
0dd3db54 56e3d1b0 56f6ae14 118a9190  python27+0x164b1b
0dd3dbd4 56e3cded 12db2468  118a9190 python27+0x12d1b0
0dd3dc0c 56e3c70f 12db6338 12db25a0 12dbe810 python27+0x12cded
0dd3dc3c 56e5820c 12db6338 12dbe810 12dbe810 python27+0x12c70f
0dd3dc60 56e5be48 118a9190 12db6338 118a94c0 python27+0x14820c
0dd3dcc4 56e5b6ec 118a9190 118a94c0 0f288ce8 python27+0x14be48
0dd3dce0 56e5b1b2 118a9190 0f288ce8 118a94c0 python27+0x14b6ec
0dd3dd18 56e5b972 56fbe178 118a9190 118a9190 python27+0x14b1b2
0dd3dd48 56e5ae86 56fbe178 56fbe178 12da18d4 python27+0x14b972
0dd3dd78 56e5886d  12da9270 12da9270 python27+0x14ae86
0dd3dd98 56e3783a 12da18d4 12da9270 12da9270 python27+0x14886d
0dd3ddc8 56deccc7  12db8150  python27+0x12783a
0dd3dde8 56db1ac6 0d125f30 12db8150  python27+0xdccc7
0dd3de04 56e3c6aa 0d125f30 12db8150  python27+0xa1ac6
0dd3de20 56e3efcf 0d125f30 12db8150  python27+0x12c6aa
0dd3dea8 56e3cded 11b72800  118a8800 python27+0x12efcf
0dd3dee0 56e3c70f 12da8b18 11b72938 12da9270 python27+0x12cded
0dd3df10 56e5820c 12da8b18 12da9270 12da9270 python27+0x12c70f
0dd3df34 56e5be48 118a8800 12da8b18 118a86f0 python27+0x14820c
0dd3df98 56e5b6ec 118a8800 118a86f0 0f288ea8 python27+0x14be48
0dd3dfb4 56e5b1b2 118a8800 0f288ea8 118a86f0 python27+0x14b6ec
0dd3dfec 56e5b972 12a6bd90 118a880d 118a8800 python27+0x14b1b2
0dd3e01c 56e5ae86 12a6bd90 12a6bd90 12a6bdd4 python27+0x14b972
0dd3e04c 56e5886d  12dbec00 12dbec00 python27+0x14ae86
0dd3e06c 56e3783a 12a6bdd4 12dbec00 12dbec00 python27+0x14886d
0dd3e09c 56deccc7  12a44390  python27+0x12783a
0dd3e0bc 56db1ac6 0d125f30 12a44390  python27+0xdccc7
0dd3e0d8 56e3c6aa 0d125f30 12a44390  python27+0xa1ac6
0dd3e0f4 56e3efcf 0d125f30 12a44390  python27+0x12c6aa
0dd3e17c 56e3cded 12883370  118a8b30 python27+0x12efcf
0dd3e1b4 56e3c70f 12a58ec0 128834a8 12dbec00 python27+0x12cded
0dd3e1e4 56e5820c 12a58ec0 12dbec00 12dbec00 python27+0x12c70f
0dd3e208 56e5be48 118a8b30 12a58ec0 118a85e0 python27+0x14820c
0dd3e26c 56e5b6ec 118a8b30 118a85e0 0f289500 python27+0x14be48
0dd3e288 56e5bc08 118a8b30 0f289500 118a85e0 python27+0x14b6ec
0dd3e2b8 56e5b724 118a8b30 118a8c40 12f14918 python27+0x14bc08
0dd3e2d0 56e5b1b2 118a8b30  118a8c40 python27+0x14b724
0dd3e308 56e5b972 128b1d90 118a8b38 118a8b30 python27+0x14b1b2
0dd3e338 56e5ae86 128b1d90 128b1d90 12a6b

Re: [Python-Dev] Forward of moderated message

2018-05-30 Thread Brett Cannon 
If you look you will see this is being executed from within Kodi, so this
is probably an embedding situation where Kodi has a bug and they are
triggering a crash in the interpreter.

On Wed, 30 May 2018 at 09:22  wrote:

>
>
>
> -- Forwarded message --
> From: "Oscar Ortiz Garcia (Axelerate LLC)" 
> To: "[email protected]" 
> Cc: Windows Developer Engagements - AppQuality 
> Bcc:
> Date: Wed, 30 May 2018 16:03:51 +
> Subject: Windows Application Issue | Python Software Foundation | REF #
> 12927041
>
> Dear Windows developer,
>
> I’m a program manager in the Partner App Experience Team at Microsoft.
> We’re reaching out to notify you of a potential issue in one of your
> applications. This issue is automatically generated by Windows Error
> Reporting, a system which generates an error report whenever a crash
> happens on user’s machine.
>
> The issue details are below. Our goal is to work with you to address this
> issue and to understand what your expected timeline to address this issue
> might be. If you have any questions about the details below or have already
> addressed this issue in a forthcoming update, please let me know.
>
> *Issue*
>
> *Appcrash in
> FAIL_FAST_FATAL_APP_EXIT_DETOURS_c409_python27.dll!PyMapping_HasKey*
>
> *Product*
>
> Python
>
> *Module*
>
> python27.dll
>
> *Module Version*
>
> 2.7.12150.1013
>
> *OS*
>
> Windows 10 Insider Preview, Windows 10
>
> *OS Version*
>
> 17134, 16299, 15063, 14393
>
> *OS Architecture*
>
> x64, x86
>
> *Environment*
>
> Desktop
>
> *Occurrence*
>
> More than 0.1M hits in the last 14 days
>
> *Impacted Locations*
>
> US, Canada, Europe, Brazil
>
> *Triage Notes*
>
> PROCESS_NAME:  kodi.exe
>
> ERROR_CODE: (NTSTATUS) 0xc409 - The system detected an overrun of a
> stack-based buffer in this application. This overrun could potentially
> allow a malicious user to gain control of this application.
>
> EXCEPTION_CODE: (NTSTATUS) 0xc409 - The system detected an overrun of
> a stack-based buffer in this application. This overrun could potentially
> allow a malicious user to gain control of this application.
>
>
>
> WATSON_BKT_PROCVER:  17.6.0.0
>
> WATSON_BKT_MODULE:  ucrtbase.dll
>
> WATSON_BKT_MODVER:  10.0.17134.1
>
>
>
> PROBLEM_CLASSES:
>
>
>
> ID: [0n278]
>
> Type:   [FAIL_FAST]
>
> Class:  Primary
>
> Scope:  DEFAULT_BUCKET_ID (Failure Bucket ID prefix)
>
> BUCKET_ID
>
> Name:   Add
>
> Data:   Omit
>
> PID:[Unspecified]
>
> TID:[Unspecified]
>
> Frame:  [0]
>
>
>
> ID: [0n267]
>
> Type:   [FATAL_APP_EXIT]
>
> Class:  Addendum
>
> Scope:  DEFAULT_BUCKET_ID (Failure Bucket ID prefix)
>
> BUCKET_ID
>
> Name:   Add
>
> Data:   Omit
>
> PID:[Unspecified]
>
> TID:[Unspecified]
>
> Frame:  [0]
>
>
>
> ID: [0n138]
>
> Type:   [DETOURS]
>
> Class:  Addendum
>
> Scope:  DEFAULT_BUCKET_ID (Failure Bucket ID prefix)
>
> BUCKET_ID
>
> Name:   Add
>
> Data:   Omit
>
> PID:[0x3308]
>
> TID:[0x2548]
>
> Frame:  [0] : ucrtbase!abort
>
>
>
> BUGCHECK_STR:  FAIL_FAST_FATAL_APP_EXIT_DETOURS
>
>
>
> STACK_TEXT:
>
> 0dd3db08 56e74b1b 00650063 00610076 003a006c ucrtbase!abort+0x4b
>
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
>
> 0dd3db54 56e3d1b0 56f6ae14 118a9190  python27+0x164b1b
>
> 0dd3dbd4 56e3cded 12db2468  118a9190 python27+0x12d1b0
>
> 0dd3dc0c 56e3c70f 12db6338 12db25a0 12dbe810 python27+0x12cded
>
> 0dd3dc3c 56e5820c 12db6338 12dbe810 12dbe810 python27+0x12c70f
>
> 0dd3dc60 56e5be48 118a9190 12db6338 118a94c0 python27+0x14820c
>
> 0dd3dcc4 56e5b6ec 118a9190 118a94c0 0f288ce8 python27+0x14be48
>
> 0dd3dce0 56e5b1b2 118a9190 0f288ce8 118a94c0 python27+0x14b6ec
>
> 0dd3dd18 56e5b972 56fbe178 118a9190 118a9190 python27+0x14b1b2
>
> 0dd3dd48 56e5ae86 56fbe178 56fbe178 12da18d4 python27+0x14b972
>
> 0dd3dd78 56e5886d  12da9270 12da9270 python27+0x14ae86
>
> 0dd3dd98 56e3783a 12da18d4 12da9270 12da9270 python27+0x14886d
>
> 0dd3ddc8 56deccc7  12db8150  python27+0x12783a
>
> 0dd3dde8 56db1ac6 0d125f30 12db8150  python27+0xdccc7
>
> 0dd3de04 56e3c6aa 0d125f30 12db8150  python27+0xa1ac6
>
> 0dd3de20 56e3efcf 0d125f30 12db8150  python27+0x12c6aa
>
> 0dd3dea8 56e3cded 11b72800  118a8800 python27+0x12efcf
>
> 0dd3dee0 56e3c70f 12da8b18 11b72938 12da9270 python27+0x12cded
>
> 0dd3df10 56e5820c 12da8b18 12da9270 12da9270 python27+0x12c70f
>
> 0dd3df34 56e5be48 118a8800 12da8b18 118a86f0 python27+0x14820c
>
> 0dd3df98 56e5b6ec 118a8800 118a86f0 0f288ea8 python27+0x14be48
>
> 0dd3dfb4 56e5b1b2 118a8800 0f288ea8 118a86f0 python27+0x14b6ec
>
> 0dd3dfec 56e5b972 12a6bd90 118a880d 118a8800 python27+0x14b1b2
>
> 0dd3e01c 56e5ae86 12a6bd90 12a6bd90 12a6bdd4 python27+0x14b972
>
> 0dd3e04c 56e5886d  12dbec00 12dbec00 python27+0x14ae86
>
> 0dd3e06c 56e3783a

Re: [Python-Dev] Forward of moderated message

2018-05-30 Thread Steve Dower 
I doubt responding to python-list-bounces made it back, so I've added
the emails from the original message.

As Brett says, this is clearly someone else's build of Python (for
starters, Python 2.7 should not be using ucrtbase.dll), so you would be
best to track them down.

Also, the best address for these issues is certainly
[email protected] and not python-list. I'm also happy to take them
directly to  at  if it's easier to pass them
on internally.

Cheers,
Steve

On 30May2018 0958, Brett Cannon wrote:
> If you look you will see this is being executed from within Kodi, so
> this is probably an embedding situation where Kodi has a bug and they
> are triggering a crash in the interpreter.
> 
> On Wed, 30 May 2018 at 09:22  > wrote:
> 
> 
> 
> 
> -- Forwarded message --
> From: "Oscar Ortiz Garcia (Axelerate LLC)"  >
> To: "[email protected] "
> mailto:[email protected]>>
> Cc: Windows Developer Engagements - AppQuality
> mailto:[email protected]>>
> Bcc: 
> Date: Wed, 30 May 2018 16:03:51 +
> Subject: Windows Application Issue | Python Software Foundation |
> REF # 12927041
> 
> Dear Windows developer,
> 
> I’m a program manager in the Partner App Experience Team at
> Microsoft. We’re reaching out to notify you of a potential issue in
> one of your applications. This issue is automatically generated by
> Windows Error Reporting, a system which generates an error report
> whenever a crash happens on user’s machine.
> 
> The issue details are below. Our goal is to work with you to address
> this issue and to understand what your expected timeline to address
> this issue might be. If you have any questions about the details
> below or have already addressed this issue in a forthcoming update,
> please let me know.
> 
> *Issue*
> 
>   
> 
> *Appcrash in
> 
> FAIL_FAST_FATAL_APP_EXIT_DETOURS_c409_python27.dll!PyMapping_HasKey*
> 
> *Product*
> 
>   
> 
> Python
> 
> *Module*
> 
>   
> 
> python27.dll
> 
> *Module Version*
> 
>   
> 
> 2.7.12150.1013
> 
> *OS*
> 
>   
> 
> Windows 10 Insider Preview, Windows 10
> 
> *OS Version*
> 
>   
> 
> 17134, 16299, 15063, 14393
> 
> *OS Architecture*
> 
>   
> 
> x64, x86
> 
> *Environment*
> 
>   
> 
> Desktop
> 
> *Occurrence*
> 
>   
> 
> More than 0.1M hits in the last 14 days
> 
> *Impacted Locations*
> 
>   
> 
> US, Canada, Europe, Brazil
> 
> *Triage Notes*
> 
>   
> 
> PROCESS_NAME:  kodi.exe
> 
> ERROR_CODE: (NTSTATUS) 0xc409 - The system detected an overrun
> of a stack-based buffer in this application. This overrun could
> potentially allow a malicious user to gain control of this
> application.
> 
> EXCEPTION_CODE: (NTSTATUS) 0xc409 - The system detected an
> overrun of a stack-based buffer in this application. This overrun
> could potentially allow a malicious user to gain control of this
> application.
> 
> __ __
> 
> WATSON_BKT_PROCVER:  17.6.0.0
> 
> WATSON_BKT_MODULE:  ucrtbase.dll
> 
> WATSON_BKT_MODVER:  10.0.17134.1
> 
> __ __
> 
> PROBLEM_CLASSES: 
> 
> __ __
> 
>     ID: [0n278]
> 
>     Type:   [FAIL_FAST]
> 
>     Class:  Primary
> 
>     Scope:  DEFAULT_BUCKET_ID (Failure Bucket ID prefix)
> 
>     BUCKET_ID
> 
>     Name:   Add
> 
>     Data:   Omit
> 
>     PID:    [Unspecified]
> 
>     TID:    [Unspecified]
> 
>     Frame:  [0]
> 
> __ __
> 
>     ID: [0n267]
> 
>     Type:   [FATAL_APP_EXIT]
> 
>     Class:  Addendum
> 
>     Scope:  DEFAULT_BUCKET_ID (Failure Bucket ID prefix)
> 
>     BUCKET_ID
> 
>     Name:   Add
> 
>     Data:   Omit
> 
>     PID:    [Unspecified]
> 
>     TID:    [Unspecified]
> 
>     Frame:  [0]
> 
> __ __
> 
>     ID: [0n138]
> 
>     Type:   [DETOURS]
> 
>     Class:  Addendum
> 
>     Scope:  DEFAULT_BUCKET_ID (Failure Bucket ID prefix)
> 
>     BUCKET_ID
> 
>     Name:   Add
> 
>     Data:   Omit
> 
>     PID:    [0x3308]
> 
>     TID:    [0x2548]
> 
>     Frame:  [0] : ucrtbase!abort
> 
> __ __
> 
> BUGCHECK_STR:  FAIL_FAST_FATAL_APP_EXIT_DETOURS
> 
> __ __
> 
> STACK_TEXT:  
> 
> 0dd3db08 56e74b1b 00650063 00610076 003a006c ucrtbase!abort+0x4b
> 
> WARNING: Stack unwind information not available. Following frames
> may be wrong.
> 
> 0dd

Re: [Python-Dev] Withdraw PEP 546? Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2018-05-30 Thread Victor Stinner 
2018-05-30 18:02 GMT+02:00 Nathaniel Smith :
> On Wed, May 30, 2018, 07:30 Victor Stinner  wrote:
>>
>> Does anyone would benefit of MemoryBIO in Python 2.7? Twisted,
>> asyncio, trio, urllib3, anyone else?
>
> Asyncio and trio are strongly py3-only. Twisted's TLS functionality is built
> around pyopenssl, so the stdlib ssl module doesn't affect them. Urllib3 uses
> the socket-wrapping APIs, not MemoryBIO. So fwiw I don't think any of those
> projects would benefit.

MemoryBIO was the key feature which allowed to implement TLS for the
ProactorEventLoop (IOCP) of asyncio.

I'm not sure that the Python 2.7 ssl module is a drop-in replacement
for pyopenssl.

Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] [RELEASE] Python 3.7.0b5 bonus beta!

2018-05-30 Thread Ned Deily 
A 3.7 update: Python 3.7.0b5 is now the final beta preview of Python 3.7,
the next feature release of Python. 3.7.0b4 was intended to be the final
beta but, due to some unexpected compatibility issues discovered during
beta testing of third-party packages, we decided to revert some changes
in how Python's 3.7 Abstract Syntax Tree parser deals with docstrings;
3.7.0b5 now behaves like 3.6.x and previous releases (refer to the
3.7.0b5 changelog for more information).

**If your code makes use of the ast module, you are strongly encouraged
to test (or retest) that code with 3.7.0b5, especially if you previously
made changes to work with earlier preview versons of 3.7.0.**

As always, please report issues found to bugs.python.org as soon as
possible. Please keep in mind that this is a preview release and its use
is not recommended for production environments. Attention macOS users:
there is now a new installer variant for macOS 10.9+ that includes a
built-in version of Tcl/Tk 8.6. This variant is expected to become the
default version when 3.7.0 releases. Check it out!

The next (and final, we hope!) preview release will be the release
candidate which is now planned for 2018-06-11, followed by the official
release of 3.7.0, now planned for 2018-06-27. You can find Python 3.7.0b5
and more information here:

https://www.python.org/downloads/release/python-370b5/

--
  Ned Deily
  [email protected] -- []

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com