Hi, I had described about the deadlock we are seeing in Heap32First and Heap32Next APIs in my previous post. Here is where you can see the post.
http://groups.google.com/group/mailing.openssl.users/browse_thread/thread/3223701a7f64a957/56d67d77c9960429?q=Deadlock+in+RAND_poll%27s+Heap32First+call# Believing that this is a problem with Windows APIs, we raised an incident with Microsoft. MS is still investigating the problem and has asked us to instead use GetProcessHeap and HeapWalk to enumerate the heap entries of the default process heap. Here is what they said " Conceptually, the biggest change between using GetProcessHeap/HeapWalk compared to Heap32First/Heap32Next is that you are accessing a heap handle to which you already have access inside of the process – the default process heap. All components are expected to use this heap and it has serialized access to ensure that multiple threads from the same process do not deadlock/corrupt the heap when accessing them simultaneously. Heap32First, on the other hand, accesses all heaps in the process, including private heaps that other components in the process created. Those private heaps might have been created with the HEAP_NO_SERIALIZE option which disallows application requested locking. Components (such as SSIS in your case) typically use this option when they perform the synchronization of memory access on their own to gain efficiency. However, if another component in the process start using those private heaps, it circumvents the synchronization that the component puts in place. " And since we lock the heap before reading its contents, the chances of another thread working on the same heap at the same time are nullified. I have made changes to RAND_win.c to use GetProcessHeap and HeapWalk APIs. Would you be interested in accommodating the fix to mainstream code? Please let me know your comments. Thanks, Sandeep
