Hi! I found out where the problem was. I'm using a thread pool service for serving client connections (not a separate thread for each client). Each client has assigned a ClientPort object which provides some callback methods for input and output processing. Appearantly my thread pool object was calling pending() before the SSL* object was fully instantiated therefore crashing the server. I had to lock the execution of pending() (using a Mutex) until the instantiation is done (and the Mutex released). The problem has gone away... Thank you all for your advices! Regards, Scerbatiuc Ion
----- Original Message ---- From: Kyle Hamilton <[EMAIL PROTECTED]> To: openssl-users@openssl.org Sent: Friday, April 18, 2008 5:32:49 PM Subject: Re: Segmentation fault in SSL_read() (Re-post) ergh. My apologies for not catching that. You're right, it shouldn't matter on the client side. Okay... going back to basics (I'm sorry if this seems a bit patronizing, I honestly don't intend it to be such), a segfault occurs on a pointer dereference, trying to gain access to memory which is invalid (i.e., the pointer's pointing somewhere it shouldn't). This means that one of your pointers has either been changed in the structure, or the memory that the pointer refers to has been deallocated (and is thus invalid). OpenSSL is just trying to use what's being provided to it, and blindly assuming that what's provided is appropriate and won't get it into trouble. Do you have the registers available from the core? If %ecx is 0x00000000, you've isolated your problem (something has called ssl_cleanup on the SSL* structure you're using, OR you're passing a NULL pointer to read into -- I'm not sure which argument is being dereferenced there, but since it looks like 32 bytes I'm conjecturing that it's the SSL* structure). If it's not, you have to take a more global view to the debugging. Since your server is multithreaded, the way that this generally happens is through concurrency issues. (My guess would be that a separate thread is doing cleanup on a live connection.) Have you given OpenSSL the locking functions that it needs in a multithreaded environment? Are you properly locking the session (NOT the SSL* structure, but the application session in your code which contains or references the SSL* structure) before you try to read from it? Are you sure that the session is valid before you start the thread to handle it? Is there a catch-up in the thread which, after being spawned, will take a lock against the session and examine it to ensure that it's still valid before trying to handle it, handle it, and then unlock it enough for other handlers to appropriate as necessary? Generally speaking, OpenSSL will not cause a SIGSEGV if it's passed valid data and valid pointers. If it's been given the proper locking methods, it will prevent itself from capriciously changing SSL* structure states while another OpenSSL thread is working with them. -Kyle H On Fri, Apr 18, 2008 at 5:44 AM, Ion Scerbatiuc <[EMAIL PROTECTED]> wrote: > > I'm not creating any MFC applications on linux. the client is for Windows > platform, but as I said I don't think the client matters. I also wrote some > client emulation on linux that emulates the behavior of the MFC clients and > the server still crashes. > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
