I've been messing around with this on and off for the last month.
I tried making the suggested change to global.h in the RSAref 2.0
distribution, crash still occurred in the same place. I tried some
other
changes to RSAref and finally tried not using RSAref. I've also
upgraded
to mod_ssl-2.1.6-1.3.3. The httpd still gets a SEGV in RSA_flags (which
is
in the file rsa_lib.c in the SSLeay distribution. So, I am turning my
attention to SSLeay now.
"Ralf S. Engelschall" wrote:
>
> On Fri, Dec 04, 1998, Larry Mulcahy wrote:
>
> > I have built mod_ssl with mod_ssl-2.1.0-1.3.3, apache_1.3.3,
> > SSLeay-0.9.0b,
> > rsaref-2.0.
> >
> > Platform is gcc 2.8.1 on an SGI Indigo2 (irix-gcc).
> >
> > When I start up the web server with 'apachectl startssl', the non-SSL
> > access works OK, but attempting SSL access causes the httpd process to
> > core dump with a message like:
> >
> > [Fri Dec 4 11:01:49 1998] [notice] httpd: child pid 52054 exit signal
> > Segmentation fault (11), possible coredump in /disk16/httpd/apache-1.3.3
> >
> > I rebuilt everything with the '-g' option and by examining the core file
> > with gdb, found that the error occurs in a function called RSA_flags:
> >
> > (gdb) bt
> > #0 0x41926e0 in RSA_flags (r=0x100abc50) at rsa_lib.c:246
> > #1 0x415c130 in ssl_set_pkey (c=0x100bb578, pkey=0x100b9cd8) at
> > ssl_rsa.c:235
> > #2 0x415c024 in SSL_use_RSAPrivateKey (ssl=0x100bb468, rsa=0x100abc50)
> > at ssl_rsa.c:211
> > #3 0x4143668 in ssl_hook_NewConnection (conn=0x100c2e60)
> > at ssl_engine_kernel.c:195
> > #4 0x1001231c in ap_start_restart ()
> > #5 0x1001231c in ap_start_restart ()
> > #6 0x1001231c in ap_start_restart ()
> > #7 0x1001231c in ap_start_restart ()
> > #8 0x1001231c in ap_start_restart ()
> > #9 0x1001231c in ap_start_restart ()
> > Cannot access memory at address 0x3c0e881.
> >
> > Any idea how to proceed? I re-downloaded rsaref20.tar.Z from
> > ftp://ftp.rsa.com/rsaref/ today in an effort to make sure I had the
> > right one.
>
> Have you noticed this paragraph in mod_ssl's INSTALL file?
>
> NOTE: RSAref has some portability problems. Especially it assumes that
> an `unsigned long int' represents a four byte word. One result of
> this bad assumption is that it fails under run-time (not
> compile-time) on platforms/CPUs, like Alphas, where larger integer
> sizes are used by the compiler. For instance when mod_ssl's `make
> certificate' command hangs, you get memory faults or Apache hangs
> when connecting to it through HTTPS, this all indicates that you
> ran into this portability problem. The solution is to replace the
> `typedef unsigned long int UINT4' in rsaref-2.0/source/global.h,
> line 26. The best is to use `typedef u_int32_t UINT4' when
> `u_int32_t' is defined by your vendor include files. If not try to
> use a standard type which is four bytes in length on your
> platform, e.g. on Alphas `typedef unsigned int UINT4' works.
>
> Perhaps your SGI box has a similar problem?
>
> Ralf S. Engelschall
> [EMAIL PROTECTED]
> www.engelschall.com
> ______________________________________________________________________
> Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
> Official Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
--
Larry Mulcahy [EMAIL PROTECTED]
http://babylon5.spaceimaging.com/
______________________________________________________________________
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
