Peter Djalaliev wrote:
I used ulimit as you told me and Apache dumped a core file at the next segmentation fault. I ran this with gdb (typed 'gdb httpd <core-file>' in the Apache 'bin' directory)For some reason, somewhere in libpthread.so.0, Apache is invoking _PR_CreateThread from ../../../../mozilla/nsprpub/pr/src/pthreads/pthreads.c. This file, however, is apparently not found, be cause I get "../../../../mozilla/nsprpub/pr/src/pthreads/pthread.c: No such file or directory." Similarly, it doesn't find sslsnce.c.
Those are files in NSPR and NSS. You could use the gdb command "file" to point to the proper file.
I've seen this happen once or twice before myself and haven't been able to track it down. In the short term I think you can ignore it.
Now, from now on, the httpd process in GDB either exits normally, or produces segmentation faults at different points of its execution.I don't always get this segmentation fault almost immediately when I start Apache. Sometimes it would produce output to the point that I starts waiting for connections, but then when I connect to it through FF, the browser would be waiting to receive the server_hello but it wouldn't come. Sometimes, the TLS handshake continues even further.
It might be worth it to build an unchanged version of NSS and try it with a browser also with a vanilla NSS and get that working, then throw your changes into the mix.
In he meantime, I checked my database, it seems to be fine, even though SSL_TRC still produces that -8174 error. I checked inside nss_engine_init.c, NSS_Initialize() returns SECSuccess. I am not quite sure this guarantees that the database is good.
Hmm, strange. What did you do to check the database? Again, if the server is coming up ok then it is likely a spurious error, though the NSS team may know better.
rob
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
