Michal Trojnara wrote:
I load an engine into Stunnel to access the private key. The engine loads without incident, but Stunnel consistently aborts when creating a session with the first peer because the thread stack is too small.
I'm not sure if it's a good idea to sacrifice stunnel scalability for compatibility with this engine. Thread stack size is one of the main limitations for the number of concurrent threads on 32-bit platforms. IMHO it's better to fix the engine code to allocate its buffers on the heap.>
What do you think?
All things considered, I must agree that reducing the engine use of the stack would be the better solution. I'll look it over and see if I can find anything sizable on the stack to move.
Thanks for the suggestion!
- Rich
Mccue, Richard Alan wrote:
All things considered, I must agree that reducing the engine use of the stack would be the better solution. I'll look it over and see if I can find anything sizable on the stack to move.
Thanks for the suggestion!
If you find that there is stack abuse on the openssl side of things, please let me know. (Patches are welcome of course, but I'm going back into that code soon anyway, so I can always dig on my own if there are reports of trouble.)
Cheers, Geoff
Looks like there is a 64K+ struct on the stack in the engine code. Very likely this is my problem. But I'll check through the openssl stuff preceding this as well, and let you know if there is anything that looks too big.
- Rich
-----Original Message----- From: Geoff Thorpe [mailto:[email protected]] Sent: Wednesday, March 26, 2008 1:07 PM To: Mccue, Richard Alan Cc: [email protected] Subject: Re: [stunnel-users] Enhancement request - Increase thread stack size
Mccue, Richard Alan wrote:
All things considered, I must agree that reducing the engine use of the stack would be the better solution. I'll look it over and see if I can find anything sizable on the stack to move.
Thanks for the suggestion!
If you find that there is stack abuse on the openssl side of things, please let me know. (Patches are welcome of course, but I'm going back into that code soon anyway, so I can always dig on my own if there are reports of trouble.)
Cheers, Geoff
-
Geoff Thorpe -
Mccue, Richard Alan