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