httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: mod_ssl broken
Date Mon, 10 Sep 2001 04:33:20 GMT
From: "Ben Laurie" <ben@algroup.co.uk>
Sent: Sunday, September 09, 2001 3:50 PM


> Sander Striker wrote:
> > 
> > Hi,
> > 
> > I have a local test machine running now.
> > subversion over http works as expected.
> > https is broken.  This is not on the svn
> > side (I didn't get that far).  mod_ssl
> > is broken when it comes to configs such
> > as these:
> > 
> > <VirtualHost _default_:443>
> >     SSLEngine on
> > 
> >     SSLCACertificatePath /var/openssl/ca/private
> >     SSLCACertificateFile /var/openssl/ca/private/cacert.pem
> > 
> >     SSLCertificateFile /var/openssl/ca/certs/striker.xs4all.nl-cert.pem
> >     SSLCertificateKeyFile /var/openssl/ca/certs/striker.xs4all.nl-key.pem
> > 
> >     DocumentRoot /opt/httpd/htdocs
> >     ServerName my.server.name
> > 
> >     <Location /svn>
> >         SSLRequireSSL
> > #        SSLVerifyClient require
> > #        SSLVerifyDepth 1
> > 
> >         DAV svn
> >         SVNPath /home/svn
> >     </Location>
> > </VirtualHost>
> > 
> > mod_ssl segfaults in ssl_config_perdir_merge:
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 1024 (LWP 9130)]
> > 0x806dd1d in ssl_config_perdir_merge (p=0x814e22c, basev=0x0,
> > addv=0x8192e4c) at ssl_engine_config.c:269
> > 269         cfgMergeArray(aRequirement);
> > (gdb) bt
> > #0  0x806dd1d in ssl_config_perdir_merge (p=0x814e22c, basev=0x0,
> > addv=0x8192e4c) at ssl_engine_config.c:269
> > #1  0x80a2c15 in ap_merge_per_dir_configs (p=0x814e22c, base=0x8192f34,
> > new_conf=0x8192c54) at config.c:262
> > #2  0x80b7376 in ap_location_walk (r=0x814e25c) at request.c:1236
> > #3  0x80b6511 in ap_process_request_internal (r=0x814e25c) at request.c:154
> > #4  0x8080ba0 in ap_process_request (r=0x814e25c) at http_request.c:284
> > #5  0x807c4fa in ap_process_http_connection (c=0x814c31c) at http_core.c:287
> > #6  0x80ac6db in ap_run_process_connection (c=0x814c31c) at connection.c:82
> > #7  0x80ac8b0 in ap_process_connection (c=0x814c31c) at connection.c:219
> > #8  0x80a13b2 in child_main (child_num_arg=0) at prefork.c:829
> > #9  0x80a150a in make_child (s=0x80e833c, slot=0) at prefork.c:916
> > #10 0x80a158c in startup_children (number_to_start=1) at prefork.c:939
> > #11 0x80a1985 in ap_mpm_run (_pconf=0x80e6ce4, plog=0x811eea4, s=0x80e833c)
> > at prefork.c:1155
> > #12 0x80a7323 in main (argc=1, argv=0xbffffdac) at main.c:431
> > #13 0x401f026a in __libc_start_main (main=0x80a6d98 <main>, argc=1,
> > ubp_av=0xbffffdac, init=0x8062460 <_init>, fini=0x80be834 <_fini>,
> >                rtld_fini=0x4000daa4 <_dl_fini>, stack_end=0xbffffd9c) at
> > ../sysdeps/generic/libc-start.c:129
> > 
> > The problem is that basev == NULL, which causes apr_array_append to barf.
> > I'll be looking into this next week (or someone working on mod_ssl will).
> 
> I've looked into this slightly, and the underlying problem is that
> ap_merge_per_dir_configs finds a previous cached merge (for /?) and
> tries to use it but the entry for mod_ssl is NULL. The URL, btw, is
> /svn.

This is very, very odd.  Would someone please post the svn create/merge dir config
code, just in case it's clobbering a sibling?  The last silly guess, perhaps we have
a subrequest where the prev->pool has been destroyed (sounds unlikely to me.)

There are no conditional create/merge results in mod_ssl, whatsoever.  Ergo, it 
should always be given a base and addv, and return a new conf.

> I got stuck at that point, coz it really isn't at all clear where the
> entry was expected to be set in the first place. BTW, all but the first
> entry in the cached merge were also NULL. I don't have time before
> bedtime to figure this out, I'm afraid.

It sounds as if I've failed to build/record/retrieve the cache->walked result
properly.  I'll hack at this a bit tommorow.  Hint, server/request.c:1085 is the
start of this block, and we should have a stack of walk_walked_t structures for
every merge performed, recorded in the (cache_walk_t*)cache->walked apr_array.

Bill


Mime
View raw message