Hi,
> UID 0 based processes? Perhaps then you have to run it on ports 8080/8443
> temporarily as a regular user to get the core. Without the coredump and a
> backtrace it's hard to find the location of the SIGSEGV.
>
Thanks for the hint, Ralf.
Meanwhile I got some closer and got at least a coredump:
#0 0xef36fd18 in RSA_flags ()
#1 0xef34ef60 in ssl_set_pkey ()
#2 0xef34ee8c in SSL_use_RSAPrivateKey ()
#3 0xef338774 in ssl_hook_NewConnection (conn=0xa7ff0)
at ssl_engine_kernel.c:196
#4 0x3054c in new_connection (p=0x922e8, server=0x64f60, inout=0x92320,
remaddr=0xefffefb8, saddr=0xefffefc8, child_num=0) at http_main.c:2975
#5 0x312ac in child_main (child_num_arg=598816) at http_main.c:3854
#6 0x31524 in make_child (s=0x64f60, slot=0, now=915037082)
at http_main.c:3994
#7 0x315bc in startup_children (number_to_start=1) at http_main.c:4021
#8 0x31b7c in standalone_main (argc=297880, argv=0x5e400) at
http_main.c:4299
#9 0x32318 in main (argc=4, argv=0xeffff244) at http_main.c:4583
(I'm just recompiling SSLeay, resulting in tommorows report)
So the SEGV remains within SSLeay (0.9.0b), but at least it's
caused by another apache module:
If I *do not* include mod_frontpage (as DSO) everything works fine :-(
also, if I *do* include mod_frontpage (as DSO) and mod_perl (16_02 as
static)
everything works fine too.
So eventually mod_frontpage destroys some stack regions or something
else ... but why will this problem be fixed with mod_perl ? who knows ?
(Another Problem I have with that mod_perl: It doesn't run as a DSO itself
with perl-5.005_02; everything is fine with perl-5.004_04, but with
a freshly installed perl-5.005_02 it core-dumps.)
Greetings,
Jan
______________________________________________________________________
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
