[issue44637] Quoting issue on header Reply-To and other address headers
Alexander Mohr added the comment: btw my work-around was to set maxheaderlen=sys.maxsize, worked for AWS SES at least -- ___ Python tracker <https://bugs.python.org/issue44637> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45932] EmailMessage incorrectly splits name and address header
Change by Alexander Mohr : -- title: EmailMessage incorrectly splits reply-to header -> EmailMessage incorrectly splits name and address header ___ Python tracker <https://bugs.python.org/issue45932> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45932] EmailMessage incorrectly splits reply-to header
New submission from Alexander Mohr :
If you have a reply-to list that contains a name with a comma it must be
quoted, however if the line length is just right python with split the name
incorrectly and not keep the quote. Note that the CC line keeps the quote in
the name but the reply-to does not, presumably since the line is slightly
longer.
example:
from email.message import EmailMessage
def main():
message = EmailMessage()
message['From'] = 'no-re...@farmersbusinessnetwork.com'
message['Reply-To'] = """MEGAN FOOOBAR
,"KDJEHGI, SCOTT KJUYT"
"""
message['To'] = """"KDJEHGI, SCOTT KJUYT" """
message['Subject'] = "does not matter"
message['CC'] = """MEGAN FOOOBAR ,"KDJEHGI,
SCOTT KJUYT" """
message.set_content('foo bar')
print(message.as_string())
if __name__ == '__main__':
main()
--
components: email
messages: 407329
nosy: barry, r.david.murray, thehesiod
priority: normal
severity: normal
status: open
title: EmailMessage incorrectly splits reply-to header
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue45932>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36098] asyncio: ssl client-server with "slow" read
Alexander Mohr added the comment: so I did some investigation into the difference between aiohttp + httpx and it appears that for some reason httpx does an extra read after the connection is closed. -- ___ Python tracker <https://bugs.python.org/issue36098> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36098] asyncio: ssl client-server with "slow" read
Alexander Mohr added the comment: I've updated https://repl.it/@thehesiod/PristineBonyBugs#main.py to contain both httpx + aiohttp testcases, and now httpx reproduces almost immediately and aiohttp is still ok -- ___ Python tracker <https://bugs.python.org/issue36098> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36098] asyncio: ssl client-server with "slow" read
Alexander Mohr added the comment: as an FYI I've reproduced this with the httpx library as well: https://repl.it/repls/PristineBonyBugs#main.py. It reproduces on this site but I've been unable to reproduce it locally. It does always reproduce on our production systems. what's interesting is that it I can't seem to be able to reproduce it with aiohttp either on that site or locally: https://repl.it/@thehesiod/PristineBonyBugs-1#main.py does aiohttp do something to avoid this scenario? -- ___ Python tracker <https://bugs.python.org/issue36098> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36098] asyncio: ssl client-server with "slow" read
Change by Alexander Mohr : -- nosy: +thehesiod ___ Python tracker <https://bugs.python.org/issue36098> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38529] Python 3.8 improperly warns about closing properly closed streams
Change by Alexander Mohr : -- nosy: +thehesiod ___ Python tracker <https://bugs.python.org/issue38529> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31033] Add argument to .cancel() of Task and Future
Alexander Mohr added the comment: @yselivanov even better :) -- ___ Python tracker <https://bugs.python.org/issue31033> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36478] backport of pickle fixes to Python 3.5.7 uses C99 for loops
Alexander Mohr added the comment: I hit this as well in debian:jessie, and if I enabled -std=c99 I hit this issue: https://github.com/dvarrazzo/py-setproctitle/issues/62 -- nosy: +thehesiod ___ Python tracker <https://bugs.python.org/issue36478> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34745] asyncio ssl memory leak
Alexander Mohr added the comment: going to close, I've verified that it fixes my original issue, ty!! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36009] weakref.ReferenceType is not a valid typing type
Alexander Mohr added the comment: doing the __future__ doesn't help anything as it is an invalid type -- ___ Python tracker <https://bugs.python.org/issue36009> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36009] weakref.ReferenceType is not a valid typing type
Alexander Mohr added the comment: I'm not a typing expert, but from what I understand you could do: class Bar: pass foo: Callable[[], Bar] = weakref.ref(Bar()) but you lose the typing weakref.ref. OTOH if you simply do: foo: weakref.ref = weakref.ref(Bar()) you lose the info of Bar ;) -- ___ Python tracker <https://bugs.python.org/issue36009> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36009] weakref.ReferenceType is not a valid typing type
New submission from Alexander Mohr : For valid types which encapsulate other types, like typing.List or typing.Tuple, you can declare what's contained in them like so: foo: typing.List[int] = [] Unfortunately weakref.ReferenceType does not allow you to do this. You get the error: >>> foo: weakref.ReferenceType[typing.Any] = None Traceback (most recent call last): File "", line 1, in TypeError: 'type' object is not subscriptable so either ReferenceType should be fixed or a new type made available. -- components: Library (Lib) messages: 335674 nosy: thehesiod priority: normal severity: normal status: open title: weakref.ReferenceType is not a valid typing type type: behavior versions: Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue36009> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34745] asyncio ssl memory leak
Change by Alexander Mohr : -- versions: +Python 3.6 ___ Python tracker <https://bugs.python.org/issue34745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34745] asyncio ssl memory leak
Alexander Mohr added the comment: sorry, by "raw" I mean in the context of aiohttp, so just using the normal python ssl context and asyncio sockets. I don't think it's an object not getting GC'd because I didn't see any increase on object counts, nor leaks per tracemalloc. I think it's some low-level native memory leaked by openssl. I've updated the gist w/ uvloop and ran with it and still get a leak, see gist + aiohttp issue for plot -- ___ Python tracker <https://bugs.python.org/issue34745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34745] asyncio ssl memory leak
New submission from Alexander Mohr :
I've been trying to track down a leak in aiohttp:
https://github.com/aio-libs/aiohttp/issues/3010
it seems like this leak now occurs with raw asyncio SSL sockets.
when the gist script is run like so: python3.7 `which mprof` run --interval=1
~/dev/test_leak.py -test asyncio_test
it slowly leaks memory. This is effectively doing the following:
URLS = {
'https://s3.us-west-2.amazonaws.com/archpi.dabase.com/style.css': {
'method': 'get',
'headers': {'User-Agent': 'Botocore/1.8.21 Python/3.6.4 Darwin/17.5.0',
'X-Amz-Date': '20180518T025044Z', 'X-Amz-Content-SHA256':
'e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855',
'Authorization': f'AWS4-HMAC-SHA256
Credential={CREDENTIAL}/20180518/us-west-2/s3/aws4_request,
SignedHeaders=host;x-amz-content-sha256;x-amz-date,
Signature=ae552641b9aa9a7a267fcb4e36960cd5863e55d91c9b45fd39b30fdcd2e81489',
'Accept-Encoding': 'identity'}
},
'https://s3.ap-southeast-1.amazonaws.com/archpi.dabase.com/doesnotexist': {
'method': 'GET' if sys.argv[1] == 'get_object' else 'HEAD',
'headers': {'User-Agent': 'Botocore/1.8.21 Python/3.6.4 Darwin/17.5.0',
'X-Amz-Date': '20180518T025221Z', 'X-Amz-Content-SHA256':
'e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855',
'Authorization': f'AWS4-HMAC-SHA256
Credential={CREDENTIAL}/20180518/ap-southeast-1/s3/aws4_request,
SignedHeaders=host;x-amz-content-sha256;x-amz-date,
Signature=7a7675ef6d70cb647ed59e02d532ffa80d437fb03976d8246ea9ef102d118794',
'Accept-Encoding': 'identity'}
}
}
class HttpClient(asyncio.streams.FlowControlMixin):
transport = None
def __init__(self, *args, **kwargs):
self.__url = kwargs.pop('url')
self.__logger = logging.getLogger()
super().__init__()
def connection_made(self, transport):
self.transport = transport
url_parts = urlparse(self.__url)
entry = URLS[self.__url]
body = f'{entry["method"]} {url_parts.path} HTTP/1.1\r\nAccept:
*/*\r\nHost: {url_parts.hostname}\r\n'
for name, value in entry['headers'].items():
body += f'{name}: {value}\r\n'
body += '\r\n'
self.transport.write(body.encode('ascii'))
self.__logger.info(f'data sent: {body}')
def data_received(self, data):
self.__logger.info(f'data received: {data}')
self.transport.close()
# asyncio.get_event_loop().call_later(1.0, )
def eof_received(self):
self.__logger.info('eof_received')
def connection_lost(self, exc):
self.__logger.info(f'connection lost: {exc}')
super().connection_lost(exc)
@classmethod
def create_factory(cls, url: str):
def factory(*args, **kwargs):
return cls(*args, url=url, **kwargs)
return factory
async def test_asyncio(ssl_context):
loop = asyncio.get_event_loop()
url =
'https://s3.ap-southeast-1.amazonaws.com/archpi.dabase.com/doesnotexist'
url_parts = urlparse(url)
port = url_parts.port or (80 if url_parts.scheme == 'http' else 443)
infos = await loop.getaddrinfo(url_parts.hostname, port,
family=socket.AF_INET)
family, type, proto, canonname, sockaddr = infos[0]
await loop.create_connection(HttpClient.create_factory(url), sockaddr[0],
port, ssl=ssl_context, family=family, proto=proto, flags=socket.AI_NUMERICHOST,
server_hostname=url_parts.hostname, local_addr=None)
async def asyncio_test():
ssl_context = ssl.create_default_context()
while True:
await test_asyncio(ssl_context)
await asyncio_test()
--
components: asyncio
messages: 325811
nosy: asvetlov, thehesiod, yselivanov
priority: normal
severity: normal
status: open
title: asyncio ssl memory leak
type: resource usage
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue34745>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34022] 6 tests fail using SOURCE_DATE_EPOCH env var
Alexander Mohr added the comment: we're compiling similar to debian and getting the same issues now only with 3.7 so interested in what the resolution is. I tried both w/ and w/o setting SOURCE_DATE_EPOCH and still get failures. -- nosy: +thehesiod ___ Python tracker <https://bugs.python.org/issue34022> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33565] strange tracemalloc results
Alexander Mohr <thehes...@gmail.com> added the comment: this is how my friends talk here, see: https://english.stackexchange.com/questions/11816/is-guy-gender-neutral -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33565] strange tracemalloc results
Alexander Mohr <thehes...@gmail.com> added the comment: of course, sorry, I meant in a gender neutral way -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33565] strange tracemalloc results
Alexander Mohr <thehes...@gmail.com> added the comment: ok fair enough, however a caveat is that it's not necessarily end of function as I was able to expand the function by a few more lines and the callstack stayed the same, however I'm guessing the interpreter was smart enough to realize the calls below the try/except had no references. it would be nice if there was a virtual "socket.__del__` or something at the end of the stack. Basically if it could plug into the extension callbacks. That way we could have a little more visibility. closing, thanks guys. This fixes the issue in botocore, on to the next related leak found via aiobotocore in aiohttp, where it now has no tracemalloc entries, so I'm guessing a leak via the ssl module to openssl :( thanks again guys for the help, I really appreciate it, I hope in the future, my some mechanism, scenarios like these will be a lot easier to decipher. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33565] strange tracemalloc results
Alexander Mohr <thehes...@gmail.com> added the comment: actually, thinking about this more on my way to work, this should NOT be closed. The callstack I initially mentioned still has no explanation and we now know is not correct. It should either have listed something related to warnings, or nothing at all () or something like that. There is no documentation to describe this behavior, think about it, it would have to be something like: "tracemalloc may give completely irrelevant callstacks". So I think this callstack still needs to be explained, and either: 1) the module should be fixed so it would give something more relevant (to give developers some foothold to realize this was related to warnings 2) For this scenario the callstack should be removed, to inform the developer that they should manually track the allocations in gdb or with some other mechanism. It would be really nice to know what c-callstacks (with parameters) trigger this tracemalloc stack. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33565] strange tracemalloc results
Alexander Mohr <thehes...@gmail.com> added the comment: Ok I've verified that the patch does indeed fix the leak detected. Thank you very much INADA for knowing that there was a leak in the warnings module, I would have never guessed, especially given the tracemalloc stack given. Had it showed a callstack where the warning was created it would have made a lot more sense. I agree this can be closed, however can the leak fix PLEASE be put into 3.6 (any any other version that needs it)? Who cares if warnings are 1.4x slower with the fix? Are you going to rationally tell me that keeping warnings fast is more important than fixing leaks? In most applications there should be no warnings so it doesn't really matter. This particular leak was causing our application to fail after running for a few days which makes it unusable in production. It's caused me a lot of days wasted in investigation. If speed was really a problem that would have been a much worthier thing to spend time on than finding leaks. leaks should be highest priority, then speed. No rational developer would have complained that warnings got slower, that's when you fix warnings, not because of leaks! :) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27535] Ignored ResourceWarning warnings leak memory in warnings registries
Alexander Mohr <thehes...@gmail.com> added the comment: not fixing this means that 3.6 slowly leaks for many people in prod. It's not often possible to fix all the warnings on large dynamic applications, I highly suggest finding a way to get this into 3.6. I bet there are a lot of frustrated people out there who don't know why their applications slowly leak. -- nosy: +thehesiod ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27535> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33565] strange tracemalloc results
Alexander Mohr <thehes...@gmail.com> added the comment: I'll try with that fix and see if the leak is fixed, is the reasoning that if the warning happens after the try/except scope and that's why the callstack has it? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33565] strange tracemalloc results
Alexander Mohr <thehes...@gmail.com> added the comment: INADA Naoki: Unfortunately you'll need to use credentials from a free AWS account: https://aws.amazon.com/free/. Then create a credentials file in ~/.aws/credentials: https://docs.aws.amazon.com/cli/latest/userguide/cli-config-files.html -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33565] strange tracemalloc results
Alexander Mohr <thehes...@gmail.com> added the comment: yes, memory does go up. If you click the botocore bug link you'll see a graph of memory usage over time. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33565] strange tracemalloc results
Alexander Mohr <thehes...@gmail.com> added the comment: that's not going to affect http://pytracemalloc.readthedocs.io/api.html#get_traced_memory. There is no filter for that :) as to your sum that's exactly what my original callstack lists: 21 memory blocks: 4.7 KiB this means 21 blocks were not released, and in this case leaked because nothing should be held onto after the first iteration (creating the initial connector in the connection pool. In the head object case that's going to be a new connector per iteration, however the old one should go away. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33565] strange tracemalloc results
Alexander Mohr <thehes...@gmail.com> added the comment: I believe your method is flawed, when enabling tracemalloc it's going to be using memory as well to store the traces. I still believe you need to use the method I mentioned and further even if we don't take into account the total memory the traces I mentioned need to be explained. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33565] strange tracemalloc results
Alexander Mohr <thehes...@gmail.com> added the comment:
here's another problem, if I change that function signature to:
def test(s3_client):
try:
method = getattr(s3_client, sys.argv[1])
method(Bucket='archpi.dabase.com', Key='doesnotexist')
except botocore.exceptions.ClientError as e:
if e.response['ResponseMetadata']['HTTPStatusCode'] != 404:
raise
print('.', end='', flush=True)
the print happens every time and the raise does not ever get hit, yet the raise
line is still marked as the top "leak" (unfreed blocks). It's really strange.
Furthermore the second top "leak" is this stack:
File "/tmp/Python-3.6.5/Lib/sre_compile.py", line 439
return prefix, prefix_skip, False
File "/tmp/Python-3.6.5/Lib/sre_compile.py", line 498
prefix, prefix_skip, got_all = _get_literal_prefix(pattern)
File "/tmp/Python-3.6.5/Lib/sre_compile.py", line 548
_compile_info(code, p, flags)
which doesn't make sense either, why would the return line be marked as having
allocated anything?
and btw I did change the implementation to start early, and then compare
differences between a snapshot at iter 20 and iter 100 and the same holds true
as I stated, there should logically be no difference between starting it later,
or starting in the beginning and comparing two snapshots as all what you're
doing in either cases is comparing two
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33565>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33565] strange tracemalloc results
Alexander Mohr <thehes...@gmail.com> added the comment: actually it does show in 3.5.2, it doesn't show when using get_object, but it does when using head_object, and they both throw the same exception, so weird. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33565] strange tracemalloc results
Alexander Mohr <thehes...@gmail.com> added the comment: so based on my last comment I just realized we could easily see if something was amiss by comparing results from python 3.5.2 to 3.6.5 and low and behold the callstack in question does not appear in the tracemalloc results from 3.5.2. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33565] strange tracemalloc results
Alexander Mohr <thehes...@gmail.com> added the comment: I realize it doesn't track leaks, it's a tool to help find leaks when used correctly :) This example should be similar to using the compare snapshots mechanism as I start tracking from a stable point (several iterations in after a gc), and then compare to another stable point several iterations later. I have a much more complicated set-up at our company but wanted to keep the example as short as people complain here about large examples. Further I realize how tracemalloc works, I have a lot of experience in leak hunting from my c++ days, I've even written my own native version of tracemalloc before (it's not hard). The top stat is what bubbles up as the largest leak after a number of runs, that's why the results are so peculiar. I've used tracemalloc before to find https://bugs.python.org/issue29870 in 3.5.2 and there the results made sense, here it makes no sense. To my understanding there should not be any interned strings or other items that would cause this particular callstack to be the top hit of unreleased blocks of memory (leaks). I still don't see any credible reason from why that callstack would be returned. I still believe there's a real bug here, perhaps there's a leak inside the python interpreter implementation it's trying to point out? I think it's worth investigating. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33565] strange tracemalloc results
Alexander Mohr <thehes...@gmail.com> added the comment: here's a version that tries to do something similar but does not reproduce the issue -- Added file: https://bugs.python.org/file47602/tracemalloc_test2.py ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33565] strange tracemalloc results
Change by Alexander Mohr <thehes...@gmail.com>: -- type: -> behavior ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33565] strange tracemalloc results
New submission from Alexander Mohr <thehes...@gmail.com>: while investigating https://github.com/boto/botocore/issues/1464 I used tracemalloc (like I've done before in 3.5.2) to try to figure out where the leak was. To my surprise tracemalloc listed stacks that didn't make any sense. Strangest example is the top result when running the attached script against python 3.6.5 in the following manner: PYTHONMALLOC=malloc /valgrind/bin/python3 /tmp/test.py head_object The top hit is listed as: 21 memory blocks: 4.7 KiB File "/tmp/test.py", line 28 raise File "/tmp/test.py", line 47 test(s3_client) File "/tmp/test.py", line 65 main() how is it that the "raise" is a leak? It doesn't make any sense to me specially given that no contexts are used in that call. Further that line is never hit because the exception is not re-thrown. Further a bunch of regular expression allocs don't make any sense either given that I've cleared the cache before doing snapshots. if someone could shed some light on why this is/isn't a bug that would be great. It seems to me that the callstacks are not related at all to the leak. -- components: Library (Lib) files: tracemalloc_test.py messages: 317002 nosy: thehesiod priority: normal severity: normal status: open title: strange tracemalloc results versions: Python 3.6 Added file: https://bugs.python.org/file47600/tracemalloc_test.py ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33526] hashlib leak on import
Alexander Mohr <thehes...@gmail.com> added the comment: closing as I'm not quite sure this is right -- stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33526] hashlib leak on import
New submission from Alexander Mohr <thehes...@gmail.com>: I'm seeing a lot of leaks via valgrind against the hashlib module. It appears that it's calling OpenSSL_add_all_digests(); on init, and never calling the corresponding EVP_Cleanup on free: https://www.openssl.org/docs/man1.1.0/crypto/OpenSSL_add_all_digests.html. I see a ton of leaks like the following: ==27765== 24 bytes in 1 blocks are still reachable in loss record 13 of 10,294 ==27765==at 0x4C28C7B: malloc (vg_replace_malloc.c:299) ==27765==by 0xA92E337: CRYPTO_malloc (in /usr/lib64/libcrypto.so.1.0.2k) ==27765==by 0xA9E325A: lh_insert (in /usr/lib64/libcrypto.so.1.0.2k) ==27765==by 0xA93103E: OBJ_NAME_add (in /usr/lib64/libcrypto.so.1.0.2k) ==27765==by 0xA9F3559: OpenSSL_add_all_digests (in /usr/lib64/libcrypto.so.1.0.2k) ==27765==by 0xA44CF02: PyInit__hashlib (_hashopenssl.c:998) ==27765==by 0x506E627: _PyImport_LoadDynamicModuleWithSpec (importdl.c:154) ==27765==by 0x506DBA7: _imp_create_dynamic_impl (import.c:2008) ==27765==by 0x5067A2A: _imp_create_dynamic (import.c.h:289) ==27765==by 0x4F3061A: PyCFunction_Call (methodobject.c:114) ==27765==by 0x503E10C: do_call_core (ceval.c:5074) ==27765==by 0x5035F30: _PyEval_EvalFrameDefault (ceval.c:3377) ==27765==by 0x502280F: PyEval_EvalFrameEx (ceval.c:718) ==27765==by 0x503A944: _PyEval_EvalCodeWithName (ceval.c:4139) ==27765==by 0x503DA4D: fast_function (ceval.c:4950) ==27765==by 0x503D3FC: call_function (ceval.c:4830) ==27765==by 0x5035563: _PyEval_EvalFrameDefault (ceval.c:3295) ==27765==by 0x502280F: PyEval_EvalFrameEx (ceval.c:718) ==27765==by 0x503D70D: _PyFunction_FastCall (ceval.c:4891) ==27765==by 0x503D922: fast_function (ceval.c:4926) ==27765==by 0x503D3FC: call_function (ceval.c:4830) ==27765==by 0x5035563: _PyEval_EvalFrameDefault (ceval.c:3295) ==27765==by 0x502280F: PyEval_EvalFrameEx (ceval.c:718) ==27765==by 0x503D70D: _PyFunction_FastCall (ceval.c:4891) ==27765==by 0x503D922: fast_function (ceval.c:4926) ==27765==by 0x503D3FC: call_function (ceval.c:4830) ==27765==by 0x5035563: _PyEval_EvalFrameDefault (ceval.c:3295) ==27765==by 0x502280F: PyEval_EvalFrameEx (ceval.c:718) ==27765==by 0x503D70D: _PyFunction_FastCall (ceval.c:4891) ==27765==by 0x503D922: fast_function (ceval.c:4926) ==27765==by 0x503D3FC: call_function (ceval.c:4830) ==27765==by 0x5035563: _PyEval_EvalFrameDefault (ceval.c:3295) ==27765==by 0x502280F: PyEval_EvalFrameEx (ceval.c:718) ==27765==by 0x503D70D: _PyFunction_FastCall (ceval.c:4891) ==27765==by 0x503D922: fast_function (ceval.c:4926) I'm not exactly sure how this is happening yet (I know the code I use does a __import__ and uses multiple threads). It sounds like this call should be ref-counted or perhaps only done once for the life of the application. -- components: Extension Modules messages: 316723 nosy: thehesiod priority: normal severity: normal status: open title: hashlib leak on import type: resource usage versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31033] Add argument to .cancel() of Task and Future
Alexander Mohr <thehes...@gmail.com> added the comment: I was about to open a new bug, but I think my idea overlaps with this one. From what I understand there are two ways to cancel tasks: 1) calling task.cancel() 2) explicitly raising a CancelledError with #2 you can get a traceback by catching the exception which yields why the task was cancelled (per callstack, and you create the CancelledError with a custom message). #1 I think is what this is talking about. The most useful information IMHO is the callstack, and via #1 this callstack is completely lost. I like the idea of having an argument to construct the CancelledError with, but I like even more the ability to tell the exception that will be raised to have the traceback of the point where the task was originally cancelled. Right now I have to use forbidden fruit to override the Task.cancel method and store the callstack in a custom attribute. I was talking with asvetlov and and he thought perhaps there could be an environment variable to enable this by default and then when the cancellation error is raised it can have the caller's callstack...I think ideally this would be the default if it could be done cheaply (given if a regular exception throw contains the callstack, then a cancellation exception should always as well. Ideally I think when a task is cancelled it instantiates the exception with the callstack at that point, and then does something like a "with e" to raise the exception from the future so you get it when it's raised. -- nosy: +thehesiod ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31033> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33221] Add stats for asyncio task usage.
Alexander Mohr <thehes...@gmail.com> added the comment: another idea would be neat to somehow plug into the stats so people can trace (ex: via datadog tracing) "slow" tasks, similarly to things that are outputted via PYTHONASYNCIODEBUG, however in this case be able to trace slow steps and also slow accumulated steps. In this scenario you don't know which task will be slow and don't want to track every task. -- nosy: +thehesiod ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33221> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32811] test_os.py fails when run in docker container on OSX host
Alexander Mohr <thehes...@gmail.com> added the comment: here's how to repro, download fresh debian:stretch image, then install reqs for python: apt-get update && apt-get install curl build-essential libssl-dev libffi-dev libmemcached-dev zlib1g-dev install pyenv-installer: curl -L https://raw.githubusercontent.com/pyenv/pyenv-installer/master/bin/pyenv-installer | bash install and activate python3.6.3: pyenv install 3.6.3 && pyenv global 3.6.3 run attached test script which I generated from the unittest -- Added file: https://bugs.python.org/file47436/test.py ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32811> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32811] test_os.py fails when run in docker container on OSX host
Alexander Mohr <thehes...@gmail.com> added the comment: sorry if my report is confusing, the issue is when run in a debian:stretch docker container on an OSX host, so running this: docker run --rm -ti docker:stretch on osx. So if you have access to an OSX machine and have docker running (18.02.0-ce-mac53) on your OSX machine it should reproduce there. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32811> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32811] test_os.py fails when run in docker container on OSX host
Alexander Mohr <thehes...@gmail.com> added the comment: btw there are some other tests that fail too after removing that test like: test test_tokenize failed -- Traceback (most recent call last): File "/build/Python-3.6.3/Lib/test/test_tokenize.py", line 1557, in test_random_files testfiles.remove(os.path.join(tempdir, "test_%s.py") % f) ValueError: list.remove(x): x not in list -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32811> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32811] test_os.py fails when run in docker container on OSX host
New submission from Alexander Mohr <thehes...@gmail.com>: This test fails when run in a debian docker container from a OSX host with the following error: test test_os failed -- Traceback (most recent call last): File "/build/Python-3.6.3/Lib/test/test_os.py", line 3273, in test_attributes self.check_entry(entry, 'dir', True, False, False) File "/build/Python-3.6.3/Lib/test/test_os.py", line 3228, in check_entry os.stat(entry.path, follow_symlinks=False).st_ino) AssertionError: 3018467 != 1419357 works fine when run on ubuntu host. If this is a docker problem I'd be happy to report there. -- components: Build messages: 311921 nosy: thehesiod priority: normal severity: normal status: open title: test_os.py fails when run in docker container on OSX host type: behavior versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32811> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32754] feature request: asyncio.gather/wait cancel children on first exception
New submission from Alexander Mohr <thehes...@gmail.com>: currently gather/wait allow you to return on the first exception and leave the children executing. A very common use case that I have is of launching multiple tasks, and if any of them fail, then all should fail..otherwise the other tasks would continue running w/o anyone listening for the results. To accomplish this I wrote a method like the following: https://gist.github.com/thehesiod/524a1f005d0f3fb61a8952f272d8709e. I think it would be useful to many others as on optional perhaps a parameter to each of these methods. What do you guys think? -- components: asyncio messages: 311527 nosy: asvetlov, thehesiod, yselivanov priority: normal severity: normal status: open title: feature request: asyncio.gather/wait cancel children on first exception versions: Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32754> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29317] test_copyxattr_symlinks fails
Change by Alexander Mohr <thehes...@gmail.com>: -- nosy: +thehesiod versions: +Python 3.5 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue29317> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29406] asyncio SSL contexts leak sockets after calling close with certain Apache servers
Alexander Mohr <thehes...@gmail.com> added the comment: my understanding is that the PR in https://bugs.python.org/issue30698 fixes this issue no? If so can we get it merged? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue29406> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30698] asyncio sslproto do not shutdown ssl layer cleanly
Alexander Mohr <thehes...@gmail.com> added the comment: @grzgrzgrz3, does this resolve the issue in https://bugs.python.org/issue29406 ? I'm guessing you based this PR on that issue. If so I'd like it merged ASAP as otherwise our prod services will be incompatible with all future python releases given the original "fix" was reverted. Thanks! -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue30698> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32448] subscriptable
Alexander Mohr <thehes...@gmail.com> added the comment: oh for second example I meant something like this: >>> class Foo: pass >>> Foo.organizer = None >>> Foo.blah = Foo >>> Foo.blah.organizer = None >>> Foo.blah.organizer[0] ya this is just a pie in the sky request :) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32448> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32448] subscriptable
New submission from Alexander Mohr <thehes...@gmail.com>: Currently subscriting a attribute that's None reports the following: >>> class Foo: pass >>> Foo.organizer = None >>> Foo.organizer['start'] Traceback (most recent call last): File "", line 1, in TypeError: 'NoneType' object is not subscriptable What would be nice is if it were to report the name of the attribute that is not subscriptable as it would greatly help in the logs, something like: Traceback (most recent call last): File "", line 1, in TypeError: 'NoneType' object of attribute 'organizer' is not subscriptable just a thought. Otherwise one would need to sprinkle their code with asserts, especially if it's a compound statement like: Foo.organizer.blah[0], you wouldn't know which attribute wasn't None -- components: Interpreter Core messages: 309187 nosy: thehesiod priority: normal severity: normal status: open title: subscriptable type: enhancement versions: Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32448> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1025395] email.Utils.parseaddr fails to parse valid addresses
Alexander Mohr added the comment: looks like these were meant to be internal methods, retracting new issues -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1025395> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1025395] email.Utils.parseaddr fails to parse valid addresses
Alexander Mohr added the comment:
from 3.6:
>>> AddrlistClass('John Smith <john.smith(comment)@example.org>').getcomment()
''
>>> AddrlistClass('John Smith <john.smith(comment)@example.org>').getdomain()
'JohnSmith'
totally messed up :)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue1025395>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1025395] email.Utils.parseaddr fails to parse valid addresses
Changes by Alexander Mohr <thehes...@gmail.com>: -- nosy: +thehesiod versions: +Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1025395> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29302] add contextlib.AsyncExitStack
Alexander Mohr added the comment: let me know if I need to do anything -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31095] Checking all tp_dealloc with Py_TPFLAGS_HAVE_GC
Alexander Mohr added the comment: my vote is yes due to the defaultdict issue. We were hitting this in our prod env -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31061] asyncio segfault when using threadpool and "_asyncio" native module
Alexander Mohr added the comment: hmm, may be my fault due to docker image tagging issue. Will redeploy and update if the issue persists. If I don't reply again sorry for the noise. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31061> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31061] asyncio segfault when using threadpool and "_asyncio" native module
Alexander Mohr added the comment: bad news, I just got a crash in the same place (updating defaultdict) after running for a week with the fixes from this and inada naoki's patches. I think the threadpool may be leaking threads too as I had > 40 threads after running for a week when I use no more than ~10. I'm going to switch to debug build and will update when I get more details. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31061> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31061] asyncio segfault when using threadpool and "_asyncio" native module
Alexander Mohr added the comment: I've verified that this along with the changes in 31095 resolve the crashes I've been seeing in our production environment -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31061> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31095] Checking all tp_dealloc with Py_TPFLAGS_HAVE_GC
Alexander Mohr added the comment: omg I just realized I need the default dict one too, great investigation work! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31095] Checking all tp_dealloc with Py_TPFLAGS_HAVE_GC
Alexander Mohr added the comment: actually another idea: could the PR for this also update https://docs.python.org/2/c-api/typeobj.html#c.PyTypeObject.tp_dealloc to mention about these macros and when they should be used? That, along with all the other locations correctly calling these macros, and having comments when they're not needed hopefully should prevent this from happening again. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31095] Checking all tp_dealloc with Py_TPFLAGS_HAVE_GC
Alexander Mohr added the comment: I suggest any places that don't need the calls should have comments so that future reviewers know why. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31095] Checking all tp_dealloc with Py_TPFLAGS_HAVE_GC
Alexander Mohr added the comment: should the base method which calls tp_dealloc do this? Maybe can kill all birds with one stone. -- nosy: +thehesiod ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31061] asyncio segfault when using threadpool and "_asyncio" native module
Alexander Mohr added the comment: ok, created: https://github.com/python/cpython/pull/2966 there are some other deallocs in there, mind verifying the rest? -- pull_requests: +3014 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31061> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31061] asyncio segfault when using threadpool and "_asyncio" native module
Alexander Mohr added the comment:
I'm hoping this is the fix:
--- Modules/_asynciomodule.c.orig 2017-07-31 12:16:16.0 -0700
+++ Modules/_asynciomodule.c2017-07-31 13:08:52.0 -0700
@@ -953,15 +953,18 @@
FutureObj_dealloc(PyObject *self)
{
FutureObj *fut = (FutureObj *)self;
+PyObject_GC_UnTrack(self);
if (Future_CheckExact(fut)) {
/* When fut is subclass of Future, finalizer is called from
* subtype_dealloc.
*/
+_PyObject_GC_TRACK(self);
if (PyObject_CallFinalizerFromDealloc(self) < 0) {
// resurrected.
return;
}
+_PyObject_GC_UNTRACK(self);
}
if (fut->fut_weakreflist != NULL) {
@@ -1828,14 +1831,18 @@
{
TaskObj *task = (TaskObj *)self;
+PyObject_GC_UnTrack(self);
+
if (Task_CheckExact(self)) {
/* When fut is subclass of Task, finalizer is called from
* subtype_dealloc.
*/
+ _PyObject_GC_TRACK(self);
if (PyObject_CallFinalizerFromDealloc(self) < 0) {
// resurrected.
return;
}
+_PyObject_GC_UNTRACK(self);
}
if (task->task_weakreflist != NULL) {
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31061>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31061] asyncio segfault when using threadpool and "_asyncio" native module
Alexander Mohr added the comment:
another core had a different gc object:
$1 = {ob_base = {ob_base = {_ob_next = 0x7f801eac3158, _ob_prev =
0x7f801eab95a0, ob_refcnt = 41, ob_type = 0x7f80238e76e0 },
ob_size = 0}, tp_name = 0x7f801e8967af "_asyncio.Task", tp_basicsize = 128,
tp_itemsize = 0,
tp_dealloc = 0x7f801e8926e5 , tp_print = 0x0, tp_getattr =
0x0, tp_setattr = 0x0, tp_as_async = 0x7f801ea99720 ,
tp_repr = 0x7f801e88fa9b , tp_as_number = 0x0, tp_as_sequence =
0x0, tp_as_mapping = 0x0,
tp_hash = 0x7f802356b995 <_Py_HashPointer>, tp_call = 0x0, tp_str =
0x7f8023442d05 , tp_getattro = 0x7f802341dc8b
, tp_setattro = 0x7f802341e0b5
, tp_as_buffer = 0x0, tp_flags = 807937,
tp_doc = 0x7f801ea98bc0 <_asyncio_Task___initdoc__> "Task(coro, *,
loop=None)\n--\n\nA coroutine wrapped in a Future.", tp_traverse =
0x7f801e891658 , tp_clear = 0x7f801e89150b ,
tp_richcompare = 0x7f8023442d42 , tp_weaklistoffset = 96,
tp_iter = 0x7f801e890d4f , tp_iternext = 0x0, tp_methods =
0x7f801ea99b20 , tp_members = 0x0, tp_getset = 0x7f801ea99d40
,
tp_base = 0x7f801ea9a3c0 , tp_dict = 0x7f801eac2238, tp_descr_get
= 0x0, tp_descr_set = 0x0, tp_dictoffset = 88, tp_init = 0x7f801e88d84d
<_asyncio_Task___init__>, tp_alloc = 0x7f802343a7f8 ,
tp_new = 0x7f802343a9c6 , tp_free = 0x7f80235a2d8b
, tp_is_gc = 0x0, tp_bases = 0x7f801eab95a0, tp_mro =
0x7f801eabc508, tp_cache = 0x0, tp_subclasses = 0x0, tp_weaklist =
0x7f801eac3458, tp_del = 0x0, tp_version_tag = 4303,
tp_finalize = 0x7f801e8922fd }
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31061>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26617] Assertion failed in gc with __del__ and weakref
Alexander Mohr added the comment:
so I just discovered that the object that has the zero refcount has the same
tp_dealloc:
(gdb) print *FROM_GC(gc)->ob_type
$8 = {ob_base = {ob_base = {_ob_next = 0x7f80c8aafc88, _ob_prev =
0x7f80c8aafd00, ob_refcnt = 7, ob_type = 0x7f80cd8c86e0 }, ob_size
= 0}, tp_name = 0x7f80c8aa5c38 "_GatheringFuture", tp_basicsize = 104,
tp_itemsize = 0,
tp_dealloc = 0x7f80cd41bee7 , tp_print = 0x0, tp_getattr =
0x0, tp_setattr = 0x0, tp_as_async = 0x556ba4342d58, tp_repr = 0x7f80c8870a9b
, tp_as_number = 0x556ba4342d70, tp_as_sequence =
0x556ba4342ea8,
tp_as_mapping = 0x556ba4342e90, tp_hash = 0x7f80cd54c995 <_Py_HashPointer>,
tp_call = 0x0, tp_str = 0x7f80cd423d05 , tp_getattro =
0x7f80cd3fec8b , tp_setattro = 0x7f80cd3ff0b5
,
tp_as_buffer = 0x556ba4342ef8, tp_flags = 808449, tp_doc = 0x7f80c8cd7380
"Helper for gather().\n\nThis overrides cancel() to cancel all the children
and act more\nlike Task.cancel(), which doesn't immediately mark itself
as\ncancelled.\n",
tp_traverse = 0x7f80cd41baae , tp_clear = 0x7f80cd41bd5c
, tp_richcompare = 0x7f80cd423d42 ,
tp_weaklistoffset = 96, tp_iter = 0x7f80c8871d4f ,
tp_iternext = 0x7f80cd3fe6d6 <_PyObject_NextNotImplemented>, tp_methods =
0x0, tp_members = 0x556ba4342f28, tp_getset = 0x0, tp_base = 0x7f80c8a7b3c0
, tp_dict = 0x7f80c8aafc88, tp_descr_get = 0x0, tp_descr_set = 0x0,
tp_dictoffset = 88,
tp_init = 0x7f80cd431000 , tp_alloc = 0x7f80cd41b7f8
, tp_new = 0x7f80cd41b9c6 , tp_free =
0x7f80cd583d8b , tp_is_gc = 0x0, tp_bases = 0x7f80c8ab20c0,
tp_mro = 0x7f80c8aafd00,
tp_cache = 0x0, tp_subclasses = 0x0, tp_weaklist = 0x7f80c8aae5d8, tp_del =
0x0, tp_version_tag = 791, tp_finalize = 0x7f80c8870ddb }
This is for a GatheringFuture, something tells me perhaps there is more to this
function that needs to be resolved?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26617>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31061] asyncio segfault when using threadpool and "_asyncio" native module
Alexander Mohr added the comment:
oh, so this is looking like an asyncio issue, the "gc" that is causing the
crash is:
(gdb) print *FROM_GC(gc)->ob_type
$8 = {ob_base = {ob_base = {_ob_next = 0x7f80c8aafc88, _ob_prev =
0x7f80c8aafd00, ob_refcnt = 7, ob_type = 0x7f80cd8c86e0 }, ob_size
= 0}, tp_name = 0x7f80c8aa5c38 "_GatheringFuture", tp_basicsize = 104,
tp_itemsize = 0,
tp_dealloc = 0x7f80cd41bee7 , tp_print = 0x0, tp_getattr =
0x0, tp_setattr = 0x0, tp_as_async = 0x556ba4342d58, tp_repr = 0x7f80c8870a9b
, tp_as_number = 0x556ba4342d70, tp_as_sequence =
0x556ba4342ea8,
tp_as_mapping = 0x556ba4342e90, tp_hash = 0x7f80cd54c995 <_Py_HashPointer>,
tp_call = 0x0, tp_str = 0x7f80cd423d05 , tp_getattro =
0x7f80cd3fec8b , tp_setattro = 0x7f80cd3ff0b5
,
tp_as_buffer = 0x556ba4342ef8, tp_flags = 808449, tp_doc = 0x7f80c8cd7380
"Helper for gather().\n\nThis overrides cancel() to cancel all the children
and act more\nlike Task.cancel(), which doesn't immediately mark itself
as\ncancelled.\n",
tp_traverse = 0x7f80cd41baae , tp_clear = 0x7f80cd41bd5c
, tp_richcompare = 0x7f80cd423d42 ,
tp_weaklistoffset = 96, tp_iter = 0x7f80c8871d4f ,
tp_iternext = 0x7f80cd3fe6d6 <_PyObject_NextNotImplemented>, tp_methods =
0x0, tp_members = 0x556ba4342f28, tp_getset = 0x0, tp_base = 0x7f80c8a7b3c0
, tp_dict = 0x7f80c8aafc88, tp_descr_get = 0x0, tp_descr_set = 0x0,
tp_dictoffset = 88,
tp_init = 0x7f80cd431000 , tp_alloc = 0x7f80cd41b7f8
, tp_new = 0x7f80cd41b9c6 , tp_free =
0x7f80cd583d8b , tp_is_gc = 0x0, tp_bases = 0x7f80c8ab20c0,
tp_mro = 0x7f80c8aafd00,
tp_cache = 0x0, tp_subclasses = 0x0, tp_weaklist = 0x7f80c8aae5d8, tp_del =
0x0, tp_version_tag = 791, tp_finalize = 0x7f80c8870ddb }
note: it's a _GatheringFuture.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31061>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26617] Assertion failed in gc with __del__ and weakref
Alexander Mohr added the comment: I'm tracking something very similar issue to this in bug: http://bugs.python.org/issue31061 Given its similarities, anyone have any ideas? Based on the second callstack I'm starting to think this is an issue with defaultdict -- nosy: +thehesiod ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26617> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31061] asyncio segfault when using threadpool and "_asyncio" native module
Alexander Mohr added the comment: btw got slightly difference stacktrace on second core file -- Added file: http://bugs.python.org/file47051/python crash2.txt ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31061> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31061] asyncio segfault when using threadpool and "_asyncio" native module
Alexander Mohr added the comment: hmm, how would I do that? btw I'm not 100% sure this is due to asyncio. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31061> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31061] asyncio segfault when using threadpool and "_asyncio" native module
Alexander Mohr added the comment:
this is the comment on the assert:
/* Python's cyclic gc should never see an incoming refcount
* of 0: if something decref'ed to 0, it should have been
* deallocated immediately at that time.
* Possible cause (if the assert triggers): a tp_dealloc
* routine left a gc-aware object tracked during its teardown
* phase, and did something-- or allowed something to happen --
* that called back into Python. gc can trigger then, and may
* see the still-tracked dying object. Before this assert
* was added, such mistakes went on to allow gc to try to
* delete the object again. In a debug build, that caused
* a mysterious segfault, when _Py_ForgetReference tried
* to remove the object from the doubly-linked list of all
* objects a second time. In a release build, an actual
* double deallocation occurred, which leads to corruption
* of the allocator's internal bookkeeping pointers. That's
* so serious that maybe this should be a release-build
* check instead of an assert?
*/
I've also attached a file that's similar to the code we run in production,
however couldn't get it to reproduce the crash. In the datafile it uses it has
some tuples like the following:
StationTuple = namedtuple('StationTuple', ['stationname', 'stationsubtype',
's2id'])
--
Added file: http://bugs.python.org/file47050/python_crash.py
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31061>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31061] asyncio segfault when using threadpool and "_asyncio" native module
Alexander Mohr added the comment: ok got a full debug core file, let me know what other information I can provide. -- status: closed -> open Added file: http://bugs.python.org/file47049/python crash.txt ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31061> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31061] asyncio segfault when using threadpool and "_asyncio" native module
Alexander Mohr added the comment: the problem with this crash is that it only happens periodically in our prod environment :( If I try running the exact same docker container with the same inputs locally it doesn't reproduce, so frustrating. I've created a whole workflow now for deploying with a debug python to get a core file with symbols. Hopefully have some more info w/in a day. Thanks for the tips! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31061> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31061] asyncio segfault when using threadpool and "_asyncio" native module
Alexander Mohr added the comment: so looks like disabling the _asyncio module just caused the crash to happen less often, closing and will continue investigating after a get a core file -- stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31061> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31061] asyncio segfault when using threadpool and "_asyncio" native module
Alexander Mohr added the comment: btw I've seen this issue in 3.5.2 + 3.6.2 on debian jessie + stretch -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31061> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31061] asyncio segfault when using threadpool and "_asyncio" native module
New submission from Alexander Mohr: I have a project in a prod environment which heavily uses asyncio and a threadpool. It uses the threadpool to run CPU heavy tasks (in this case populating a defaultdict) to avoid blocking the main thread (no async code in thread). For some time now my service has been randomly crashing at the same place in the thread which does the dict updating. I've finally got both the python and native stack traces, and based on the information presented it looked very similar to the issue found by the devs at home-assistant (https://github.com/home-assistant/home-assistant/issues/7752#issuecomment-30519, which points to https://github.com/home-assistant/home-assistant/pull/7848). So I tried their fix of disabling the "_asyncio" module, and lo and behold python no longer segfaults. Per the stacktrace it's crashing in PyObject_GC_Del, and the only place this is used in the asyncio module seems to be here: https://github.com/python/cpython/blob/master/Modules/_asynciomodule.c#L996 does anyone have any idea why it's crashing on this line? Are there thread protections missing in this file? I'm trying to reproduce this in a testcase but it's proving very difficult as I'm guessing it's timing related. -- components: asyncio files: native___python_crash_stacks.txt messages: 299346 nosy: thehesiod, yselivanov priority: normal severity: normal status: open title: asyncio segfault when using threadpool and "_asyncio" native module type: crash versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file47043/native___python_crash_stacks.txt ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31061> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30698] asyncio sslproto do not shutdown ssl layer cleanly
Changes by Alexander Mohr <thehes...@gmail.com>: -- nosy: +thehesiod ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30698> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29870] ssl socket leak
Alexander Mohr added the comment: awesome! Thanks for finding a proposing fix pitrou! btw I found an example of freeing this structure here: http://www.zedwood.com/article/c-openssl-parse-x509-certificate-pem -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29870] ssl socket leak
Alexander Mohr added the comment: see graphs here: https://github.com/kennethreitz/requests/issues/3933, x-axis is number of requests not what it says (seconds). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29870] ssl socket leak
Alexander Mohr added the comment: ya, my sample script hits google.com <http://google.com/>, it's pretty fast. It just does a "HEAD". > On Apr 11, 2017, at 9:14 AM, Antoine Pitrou <rep...@bugs.python.org> wrote: > > > Antoine Pitrou added the comment: > > Is there a fast enough remote server that shows the leak? I've tested with my > own remote server (https://pitrou.net/), but it doesn't leak. > > -- > > ___ > Python tracker <rep...@bugs.python.org> > <http://bugs.python.org/issue29870> > ___ -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29870] ssl socket leak
Alexander Mohr added the comment: the interesting part is it doesn't leak with a local https server, it appears to need to be a remove server. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29870] ssl socket leak
Alexander Mohr added the comment: yes, in the gist I created you can switch between the various clients, by default right now it uses raw sockets. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29870] ssl socket leak
Alexander Mohr added the comment: @pitrou: sys.getallocatedblocks does not seem to increase -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29302] add contextlib.AsyncExitStack
Alexander Mohr added the comment: ok I've updated the gist with a base class and sync + async sub-classes. The way it worked out I think is nice because we can have the same method names across both sync+async. Let me know what you guys think! btw, it seems the test_dont_reraise_RuntimeError test hangs even with the release version. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29870] ssl socket leak
Alexander Mohr added the comment: interestingly the valgrind run doesn't show a leak in the profile -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29870] ssl socket leak
Alexander Mohr added the comment: adding valgrind log of 3.5.3 on debian: jessie -- Added file: http://bugs.python.org/file46750/valgrind.log.gz ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29870] ssl socket leak
Alexander Mohr added the comment: validated 3.6 in fedora is affected as well, see github bug for charts. So it seems all 3.5.3+ versions are affected. I'm guessing it was introduced in one of the SSL changes in 3.5.3: https://docs.python.org/3.5/whatsnew/changelog.html#python-3-5-3 -- versions: +Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29870] ssl socket leak
New submission from Alexander Mohr: When upgrading to 3.5.3 we noticed that the requests module was leaking memory rather quickly. This led to me logging the issue: https://github.com/kennethreitz/requests/issues/3933. After more investigation I've found that the leak is caused by the raw python SSL sockets. I've created a test file here: https://gist.github.com/thehesiod/ef79dd77e2df7a0a7893dfea6325d30a which allows you to reproduce the leak with raw python ssl socket (CLIENT_TYPE = ClientType.RAW), aiohttp or requests. They all leak in a similar way due to their use of the python SSL socket objects. I tried tracing the memory usage with tracemalloc but nothing interesting popped up so I believe this is a leak in the native code. A docker cloud image is available here: amohr/testing:stretch_request_leak based on: ``` FROM debian:stretch COPY request_https_leak.py /tmp/request_https_leak.py RUN apt-get update && \ apt-get install -y python3.5 python3-pip git RUN python3 -m pip install requests git+git://github.com/thehesiod/pyca.git@fix-py3#egg=calib setproctitle requests psutil ``` I believe this issue was introduced in python 3.5.3 as we're not seeing the leak with 3.5.2. Also I haven't verified yet if this happens on non-debian systems. I'll update if I have any more info. I believe 3.6 is similarly impacted but am not 100% certain yet. -- assignee: christian.heimes components: SSL messages: 289954 nosy: christian.heimes, thehesiod priority: normal severity: normal status: open title: ssl socket leak type: resource usage versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29302] add contextlib.AsyncExitStack
Alexander Mohr added the comment: Thanks for the feedback Nick! If I get a chance I'll see about refactoring my gist into a base class and two sub-classes with the async supporting non-async but not vice-versa. I think it will be cleaner. Sorry I didn't spend too much effort on the existing gist as I tried quickly layering on async support to move on to my primary task. After doing that I noticed that the code could use some refactoring, but only after taking the time deconstructing the impl to understand how the code works. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22087] asyncio: support multiprocessing (support fork)
Alexander Mohr added the comment: I believe this is now worse due to https://github.com/python/asyncio/pull/452 before I was able to simply create a new run loop from sub-processes however you will now get the error "Cannot run the event loop while another loop is running". The state of the run loop should not be preserved in sub-processes either. -- nosy: +thehesiod versions: +Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22087> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29406] asyncio SSL contexts leak sockets after calling close with certain Apache servers
Alexander Mohr added the comment: Thanks so much for the patch! may want to change spelling of what was supposed to be "shutdown" =) Also think it's worth a comment stating why it's needed? Like certain Apache servers were noticed to not complete the SSL shutdown process. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29406> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29406] asyncio SSL contexts leak sockets after calling close with certain Apache servers
Alexander Mohr added the comment: updating to make default the error case (madis) -- Added file: http://bugs.python.org/file46470/scratch_1.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29406> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29406] asyncio SSL contexts leak sockets after calling close with certain Apache servers
Changes by Alexander Mohr <thehes...@gmail.com>: Removed file: http://bugs.python.org/file46469/scratch_1.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29406> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29406] asyncio SSL contexts leak sockets after calling close with certain Apache servers
New submission from Alexander Mohr: with the attached code note how HttpClient.connection_lost callback is never called for the madis server. The madis server is an apache server, I tried with the OSX apache server and could not reproduce the issue so it seems something particular about their apache version or configuration. This is a pretty critical issue as close() does not release the socket. -- components: asyncio files: scratch_1.py messages: 286573 nosy: gvanrossum, thehesiod, yselivanov priority: normal severity: normal status: open title: asyncio SSL contexts leak sockets after calling close with certain Apache servers type: resource usage versions: Python 3.5 Added file: http://bugs.python.org/file46469/scratch_1.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29406> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29302] add contextlib.AsyncExitStack
Alexander Mohr added the comment: created gist: https://gist.github.com/thehesiod/b8442ed50e27a23524435a22f10c04a0 I've now updated the imple to support both __aenter__/__aexit__ and __enter__/__exit__ so I don't need two ExitStacks -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29302] add contextlib.AsyncExitStack
Changes by Alexander Mohr <thehes...@gmail.com>: Removed file: http://bugs.python.org/file46322/exit_stack.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29302] add contextlib.AsyncExitStack
New submission from Alexander Mohr: ExitStack is a really useful class and would be a great to have an async version. I've gone ahead and created an implementation based on the existing Python 3.5.2 implementation. Let me know what you guys think. I think it would be possible to combine most of the two classes together if you guys think it would be useful. Let me know if I can/should create a github PR and where to do that. -- components: Library (Lib) files: exit_stack.py messages: 285687 nosy: thehesiod priority: normal severity: normal status: open title: add contextlib.AsyncExitStack type: enhancement versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46322/exit_stack.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28342] OSX 10.12 crash in urllib.request getproxies_macosx_sysconf and proxy_bypass_macosx_sysconf
Alexander Mohr added the comment: I'm sure it would work, I just wanted a solution that didn't changes to our build infrastructure. btw if we're marking this as a duplicate of the other bug, can we update the other bug to say it affects python3.x as well? Thanks! -- status: pending -> open ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28342> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28342] OSX 10.12 crash in urllib.request getproxies_macosx_sysconf and proxy_bypass_macosx_sysconf
Alexander Mohr added the comment: ya I did a monkey patch which resolved it. if sys.platform == 'darwin': import botocore.vendored.requests.utils, urllib.request botocore.vendored.requests.utils.proxy_bypass = urllib.request.proxy_bypass_environment botocore.vendored.requests.utils.getproxies = urllib.request.getproxies_environment urllib.request.proxy_bypass = urllib.request.proxy_bypass_environment urllib.request.getproxies = urllib.request.getproxies_environment -- status: pending -> open ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28342> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28342] OSX 10.12 crash in urllib.request getproxies_macosx_sysconf and proxy_bypass_macosx_sysconf
Alexander Mohr added the comment: interestingly I haven't been able to get this to crash in a separate test app. There must be either timing related to some interaction with another module. let me know how you guys would like to proceed. I can definitely reproduce it consistently in our application. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28342> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
