From 090244c6a4b56a989cfb01bea52cb08ba389f5b2 Mon Sep 17 00:00:00 2001 From: Ryan Snyder Date: Mon, 21 Oct 2019 09:01:46 -0400 Subject: windows: interim workaround for windows segment heap bug --- python/downloadprovider.py | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) (limited to 'python/downloadprovider.py') diff --git a/python/downloadprovider.py b/python/downloadprovider.py index 27f007ff..6ba2ac9d 100644 --- a/python/downloadprovider.py +++ b/python/downloadprovider.py @@ -214,6 +214,40 @@ else: import requests if sys.platform != "win32": from requests import pyopenssl + elif core.BNIsUIEnabled(): + try: + # since requests will use urllib behind the scenes, which will use + # the openssl statically linked into _ssl.pyd, the first connection made + # will attempt to walk the entire process heap on windows using Heap32First + # and Heap32Next, which is O(n^2) in heap allocations. by doing this now, + # earlier and before threads are started, hopefully we dodge some of the impact. + # this should also help with some issues where when Heap32First fails to walk the + # heap and causes an exception, and because openssl 1.0.2q's RAND_poll implementation + # wraps this all in a __try block and silently eats said exception, when the windows + # segment heap is explicitly turned on this leaves the heap in a locked state resulting + # in process deadlock as other threads attempt to allocate or free memory. + # + # as an additional *delightful* addendum, it turns out that when the windows segment + # heap is manually flipped on, Heap32First/Heap32Next being called while another + # thread is interacting with the allocator can deadlock (or outright crash) the entire + # process. + # + # considering that this can be reproduced in a 60 line C file that mallocs/frees in a loop + # while another thread just runs the toolhelp example code from msdn, this is probably + # a windows bug. if it's not, then it's an openssl bug. ugh. + # + # radioactive superfund site workaround follows: + # RAND_status should cause the broken openssl code to run before too many threads are + # started in the UI case. this drastically reduces the repro rate in the interim. it still + # happens occasionally; threads spawned by the intel graphics drivers seem to still get hit here, + # but only ~1/2 the time. on machines i've interacted with personally, this drops repro rate to 0%. + # + # TODO FIXME remove asap when windows patch/hotfix (hopefully) gets released + import _ssl + _ssl.RAND_status() + except: + pass + class PythonDownloadInstance(DownloadInstance): def __init__(self, provider): super(PythonDownloadInstance, self).__init__(provider) -- cgit v1.3.1