It's not the CryptoAPI calls that are taking time - nearly all of the time is spent within Heap32Next. Thus my hypothesis is that CryptAcquireContextW or CryptGenRandom is failing, causing 'good' to be 0 and the heap traversal to be unbounded.
I see the "entrycnt = 80" constraint on walking the length of each heaplist, but there is no bound on the outer while loop calling Heap32ListNext? You say that "very first block of heap" is retrieved when good is 0 - is that because "GetTickCount() < stoptime" is supposed to be a short-circuit when stoptime == 0? (It's not - perhaps I should examine next whether GetTickCount is malfunctioning, or returning a signed negative int for comparison) The problem does occur with full admin privileges. I might speculate about the effect the WoW layer has on using the Heap32* functions, but my investigation so far is focused on why the traversal isn't bounded (i.e. the CryptoAPI --> good relationship), as 4 seconds (1 each for heap/process/thread/module) would be tolerable. I have not yet written a standalone C program that simulates the same CryptoAPI call sequence. If no one on this list can say "Yes, the RAND_Poll CryptoAPI calls work on Windows-7", this will be my next step. Thanks, James On Sun, Nov 8, 2009 at 6:36 AM, sandeep kiran p <sandeepkir...@gmail.com> wrote: >>RAND_poll runs very quickly with a near-empty heap. > Do you mean that the calls > to Heap32First, Heap32Next, Heap32ListFirst, Heap32ListNext are failing? Can > you check the return values from these calls? (using GetLastError?). In any > case, the heap traversals are bounded by the 1 sec limit. Even if the > variable "good" is 0, the very first block of heap allocated by the current > process is retrieved. Can you exactly specify which CryptoAPI is taking so > much time? > -Sandeep > > On Fri, Nov 6, 2009 at 11:45 AM, James Baker <j...@j-baker.org> wrote: >> >> Background: Testing a Ruby app on 64-bit Windows 7 Ultimate, I found >> that OpenSSL::PKey::RSA.generate() was taking 98 seconds. Jumping to >> C, sampling showed that the great majority of this time was spent in >> Heap32Next, which led me to the "heap list and heap walking" section >> of RAND_poll in crypto/rand/rand_win.c >> >> The heap walking (and thread and module walking) are limited to 1s >> unless the variable "good" is set, and advapi32.dll is loaded, which >> means that "poll the CryptoAPI PRNG" using the conjunction of >> CryptAcquireContextW and CryptGenRandom must be failing. >> >> The 98 seconds comes from walking the contents of the heap after >> loading a Rails environment - RAND_poll runs very quickly with a >> near-empty heap. Are the crypo-API calls ever expected to fail under >> any Windows platform, or is this the abnormality? I'm not aware of any >> changes in Win7 that would break those calls (though I'm investigating >> whether something permission/security-related is in play here), but >> I'm not aware of much about Win7 in general. I also don't see any >> Win7-related changes in the OpenSSL changelog - has this platform been >> validated already? >> >> Thanks, >> James >> ______________________________________________________________________ >> OpenSSL Project http://www.openssl.org >> User Support Mailing List openssl-us...@openssl.org >> Automated List Manager majord...@openssl.org > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
