date:20170322

[issue29885] Allow GMT timezones to be used in datetime.

2017-03-22 Thread Serhiy Storchaka


Serhiy Storchaka added the comment:

Use pytz (https://pypi.python.org/pypi/pytz).

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29881] Add a new private API for "static C variables" (_PyStaticVar) to clear them at exit

2017-03-22 Thread Serhiy Storchaka


Serhiy Storchaka added the comment:

The patch contains an example of using _Py_STATICVAR(). But it doesn't use 
_PY_STATICVAR_INIT(). _PY_STATICVAR_INIT() can be used if extract the code of 
getting _array_reconstructor into separate function.

I like the idea in general, but I want to see more examples. Ideally -- the 
patch should use a new API for *all* static PyObject* variables. This will help 
to design good API.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29885] Allow GMT timezones to be used in datetime.

2017-03-22 Thread Decorater


New submission from Decorater:

I noticed that there is no ways to convert local times to GMT if I realize that 
some other object (sometimes from a server) is using GMT and they happen to be 
ahead of my current time. As such it would be great if one can convert their 
current time that can be in an datetime object to an GMT time to see how much 
time has passed since something happened on their zone if so desired (otherwise 
can cause undesired or undefined consequences).

--
components: Library (Lib)
messages: 290027
nosy: Decorater
priority: normal
severity: normal
status: open
title: Allow GMT timezones to be used in datetime.
versions: Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29884] faulthandler does not properly restore sigaltstack during teardown

2017-03-22 Thread Christophe Zeitouny


Changes by Christophe Zeitouny :


--
pull_requests: +682

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29884] faulthandler does not properly restore sigaltstack during teardown

2017-03-22 Thread Christophe Zeitouny


Changes by Christophe Zeitouny :


Added file: http://bugs.python.org/file46755/python_reproducer.cpp

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29884] faulthandler does not properly restore sigaltstack during teardown

2017-03-22 Thread Christophe Zeitouny

New submission from Christophe Zeitouny:

Looks like faulthandler is not properly tearing down its sigaltstack, causing
potential double-free issues in any application that embeds the Python
interpreter.
I stumbled upon this when I enabled AddressSanitizer on my application, which
sets up and tears down a Python interpreter instance at runtime.
AddressSanitizer complained about a double-free of the stack_t::ss_sp memory
region.
After close inspection, here's what's happening:

1. When a new thread is created, AddressSanitizer sets up its own alternative
stack by calling sigaltstack
2. Py_Initialize() is called, which initializes faulthandler, which sets up its
own alternative stack, therefore overriding the one installed by
AddressSanitizer
3. Py_Finalize() is called, which deinitializes faulthandler, which merely
deletes the allocated stack region, but leaves the alternative stack installed.
Any signal that occurs after this point will be using a memory region it
doesn't own as stack. dangerous stuff.
4. The thread exits, at which point AddressSanitizer queries sigaltstack for
the current alternative stack, blindly assumes that it's the same one that it
installed, and attempts to free the allocated stack region. Therefore causing a
double free issue

Regardless of the fact that AddressSanitizer should probably not blindly trust
that the currently installed sigaltstack is the same one it installed earlier,
the current code in faulthandler leaves the sigaltstack in a very bad state
after finalizing.
This means that the application that embeds the Python interpreter better hope
that no signals are raised after it calls Py_Finalize().

I have a patch that fixes this issue. faulthandler will save the previously
installed alternative stack at initialization time. During deinitialization, it
will query sigaltstack for the current stack. If it's the same as the one it
installed,
it will restore the saved previous stack.

'sigaltstack' just sounds like a badly designed API. There is essentially no
way to use it 'correctly'.
Here's how AddressSanitizer uses it (line 164):
http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/sanitizer_common/sanitizer_posix_libcdep.cc?view=markup
and here's how the Chrome browser uses it:
https://chromium.googlesource.com/breakpad/breakpad/+/chrome_43/src/client/linux/handler/exception_handler.cc#149

Notice that my approach is closer to what Chrome does, but in the case where
the installed stack is no longer ours, I don't disable whatever stack is
installed. This is because I don't believe that will make much difference.
Whoever switched out the stack could have
saved our stack somewhere and planned on blindly restoring it upon exit. In
which case, whatever we do would be overridden.

Attached are a tiny reproducer for the issue, along with the complete analysis
of what's reported by AddressSanitizer. I'll follow this up by a pull request
for my changes.

Thanks!
Chris

--
components: Extension Modules
files: python_failure.txt
messages: 290025
nosy: haypo, tich
priority: normal
severity: normal
status: open
title: faulthandler does not properly restore sigaltstack during teardown
type: enhancement
Added file: http://bugs.python.org/file46754/python_failure.txt

73 matches

Mail list logo