windows: interim workaround for windows segment heap bug

1 files changed, 34 insertions, 0 deletions

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)