Hi, Using OpenSSL 0.9.8j via LibCurl 7.19.5, we've discovered some random crashes and deadlocks that, after further investigations, led us to a call to RAND_screen() from LibCurl.
Two things puzzles me about the implementation of RAND_screen(), hinting that it could maybe be a thread safety issue. Hopefully, someone around here can enlighten me on the situation. 1. RAND_screen() is not protected by locks. 2. RAND_screen() does not check whether RAND_poll() was already called before. This seems to go against what most functions in OpenSSL do. One of the best example is ssleay_rand_status() located in crypto/rand/md_rand.c. This function protects the call to RAND_poll() by locks and ensures RAND_poll() is called once and only once. Is RAND_screen() implementation correct? Or should it be protected by locks and share the initialized global variable in md_rand.c? I was thinking about maybe replacing void RAND_screen(void) { RAND_poll(); readscreen(); } by something like void RAND_screen(void) { ssleay_rand_status(); readscreen(); } which would be quite similar but would rely on the thread safety of ssleay_rand_status() to call RAND_poll(). Note however that this replacement will not work as it is because ssleay_rand_status() is declared static in an other compilation unit. Cheers, Tanguy PS: For the moment, I've worked around the problem by disabling the RAND_screen() call in LibCurl. Thankfully, LibCurl has a config flag for this. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org