[issue30385] Segfault on OSX with 3.6.1

ThePokestarFan added the comment: A pythonic way to do it is `os.environ[“no_proxy”]=“*”` -- nosy: +ThePokestarFan ___ Python tracker ___

[issue30385] Segfault on OSX with 3.6.1

Gunnar Aastrand Grimnes added the comment: Adding env no_proxy='*' does indeed fix it! Thanks a lot! I guess it's pretty hard to fix. Or even to detect, so that one could log a warning before dying :( -- ___ Python tracker

[issue30385] Segfault on OSX with 3.6.1

Ned Deily added the comment: Unfortunately, his is a long standing problem when using Python applications that fork on macOS and that end up calling certain system frameworks that under the covers use the system libdispatch which is not fork safe. In this case, it is most likely due to a

[issue30385] Segfault on OSX with 3.6.1

Daniel Birnstiel added the comment: I am currently (occasionally) running into the same problem, using Python 3.6.0 on OSX 10.12.3. I cannot reproduce this segmentation fault reliably, it happens after running for a while in production. This appears to be similar to issue 13829. python

[issue30385] Segfault on OSX with 3.6.1

Gunnar Aastrand Grimnes added the comment: I am unable to reduce it to a small(ish) test-case like for 3.6.1, but I can also get 2.7.1 to seg fault in my original program, and the stack trace is similar: Process: Python [4023] Path:

[issue30385] Segfault on OSX with 3.6.1

New submission from Gunnar Aastrand Grimnes: This script, using requests and multiprocessing, will segfault on MacOS 16.4.0 with python 3.6.1. In 3.6.0 it runs fine. The program is reduced from a much larger program, some weird things need to be present to trigger the crash. For instance the