You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Joe Orton <jo...@redhat.com> on 2005/06/02 15:05:05 UTC

Re: svn commit: r178990 - in /httpd/httpd/trunk: CHANGES server/config.c

On Sun, May 29, 2005 at 09:39:40PM -0000, Paul Querna wrote:
> Author: pquerna
> Date: Sun May 29 14:39:39 2005
> New Revision: 178990
> 
> URL: http://svn.apache.org/viewcvs?rev=178990&view=rev
> Log:
> - Use a hash for the configuration command lookup implementation.  Now
> modules can properly directives without dependence on the LoadModule
> order.

It seems this has broken the test suite somehow, it's failing to start
up with mod_ssl issuing the error:

[Thu Jun 02 14:01:14 2005] [error] Init: Multiple RSA server certificates not allowed

if I revert this revision it works again.  Any ideas?

joe

Re: svn commit: r178990 - in /httpd/httpd/trunk: CHANGES server/config.c

Posted by Paul Querna <ch...@force-elite.com>.
Joe Orton wrote:
> On Thu, Jun 02, 2005 at 02:05:05PM +0100, Joe Orton wrote:
> 
>>On Sun, May 29, 2005 at 09:39:40PM -0000, Paul Querna wrote:
>>
>>>Author: pquerna
>>>Date: Sun May 29 14:39:39 2005
>>>New Revision: 178990
>>>
>>>URL: http://svn.apache.org/viewcvs?rev=178990&view=rev
>>>Log:
>>>- Use a hash for the configuration command lookup implementation.  Now
>>>modules can properly directives without dependence on the LoadModule
>>>order.
>>
>>It seems this has broken the test suite somehow, it's failing to start
>>up with mod_ssl issuing the error:
>>
>>[Thu Jun 02 14:01:14 2005] [error] Init: Multiple RSA server certificates not allowed
>>
>>if I revert this revision it works again.  Any ideas?
> 
> 
> The problem is that the directive->module mapping is never getting
> removed when the DSO is unloaded, so during normal startup each
> directive will appear in the hash table twice for DSOs; then once more
> for each restart.  Hence mod_ssl is confused.
> 
> This is pretty dangerous since the module might *not* be reloaded again
> during a restart but the reference remains.  And since everything is
> allocated out of the global pool it's leaking memory across restarts
> too.

Opps.  Fixed in r179617.  It now does everything out of the pconf pool,
which leads to some hackish code to re-add the prelinked modules, but it
all seems correct now on graceful restarts.

<dream>I really don't like how graceful works.  Maybe after rewriting
the entire configuration system it will be better.</dream>

> plus much style badness for a third criticism, while I'm here ;)
> 
>     apr_pool_t* tpool;
>     ap_mod_list* mln;

Fixed in r179618.  I should almost write a pre-commit hook to catch
these for me, the * next to the type just seems more natural to me....

Thanks,

Paul

Re: svn commit: r178990 - in /httpd/httpd/trunk: CHANGES server/config.c

Posted by Joe Orton <jo...@redhat.com>.
On Thu, Jun 02, 2005 at 02:05:05PM +0100, Joe Orton wrote:
> On Sun, May 29, 2005 at 09:39:40PM -0000, Paul Querna wrote:
> > Author: pquerna
> > Date: Sun May 29 14:39:39 2005
> > New Revision: 178990
> > 
> > URL: http://svn.apache.org/viewcvs?rev=178990&view=rev
> > Log:
> > - Use a hash for the configuration command lookup implementation.  Now
> > modules can properly directives without dependence on the LoadModule
> > order.
> 
> It seems this has broken the test suite somehow, it's failing to start
> up with mod_ssl issuing the error:
> 
> [Thu Jun 02 14:01:14 2005] [error] Init: Multiple RSA server certificates not allowed
> 
> if I revert this revision it works again.  Any ideas?

The problem is that the directive->module mapping is never getting
removed when the DSO is unloaded, so during normal startup each
directive will appear in the hash table twice for DSOs; then once more
for each restart.  Hence mod_ssl is confused.

This is pretty dangerous since the module might *not* be reloaded again
during a restart but the reference remains.  And since everything is
allocated out of the global pool it's leaking memory across restarts
too.

plus much style badness for a third criticism, while I'm here ;)

    apr_pool_t* tpool;
    ap_mod_list* mln;

joe