You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Mladen Turk <mt...@apache.org> on 2005/09/05 09:54:51 UTC

LoadModule questions on WIN32

Hi,

Since we have a problem with recent patched from Jim for
loadbalancer, that basically core dumps WIN32 build, and
I suppose other platforms are working OK, I've done some
debugging adding traces to the various stages in module
loading and initialization, so I have a question if this
is correct behavior on all platforms.

1. LoadModule order in conf file defined the module
    loading order.
    That is correctly handled.

2. First thing called is register_hooks table.
    Suppose that is correct too.

Now, I would expect that the third hook called is 'pre_config',
but here is what happens for:

proxy_module --> [P]
proxy_balancer_module --> [B]


1. [P] register_hooks
2. [P] create_server_config
3. [P] create_dir_config
4. [B] register_hooks
5. [P] pre_config
6. [B] pre_config

So, both create server config and create dir config hooks are
called before the balancer module is loaded, and thus the function for
obtaining lbmethods is NULL, that later makes core dump on
the first request.

Also, I always thought that pre_config hook should precede any other
config hook.

If the upper scenario is correct, the only way to resolve the current
core dump is to revert the patch Jim made, because the current code
tries to load the function from the module that is not loaded jet.

Other option would be to use the APR optional functions, obtained
in the pre_config, but then again the create_server_config would
fail, because it is called before pre_config.


Regards,
Mladen.



Re: LoadModule questions on WIN32

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Paul Querna wrote:
> [..snip..]
> 
> IMO, this sure sounds like a bug in the way the WINNT MPM operates. I
> believe it should be changed to match the same pattern as all the other
> MPMs.

Within reason, I agree.  In fact I had (at one point) ensured they were
all in sync.  Apparently some patch botched that.

Note Win32 will never 'fork()' children, so the initialization of the
parent is independent of the child.  If you make half-assed assumptions
in modules that 'it's just done right' win32, as well as other poorly
forking implementation (OS/X with it's piss-poor fork() performance
comes to mind) might just break.

One thing we need is a parent->child transition API which is immune from
the lack-of-fork().  If you peek into the pass/read listener() logic
buried inside of mpm_winnt.c, you will see why this needs to be much
more abstract and approachable, before we expect unix-oriented authors
to just 'get it right'.

Re: LoadModule questions on WIN32

Posted by Mladen Turk <mt...@apache.org>.
Paul Querna wrote:
>>
>>proxy_module --> [P]
>>proxy_balancer_module --> [B]
>>
>>
>>1. [P] register_hooks
>>2. [P] create_server_config
>>3. [P] create_dir_config
>>4. [B] register_hooks
>>5. [P] pre_config
>>6. [B] pre_config
>>
> 
> [..snip..]
> 
> IMO, this sure sounds like a bug in the way the WINNT MPM operates. I
> believe it should be changed to match the same pattern as all the other
> MPMs.
>

Huh,
looking at the code, seems that there is something really weired :)

In any case, on all platforms the 'ap_single_module_configure' function
called from mod_so/load_module will call the module's
(*m->create_server_config)(p, s)
and...
(*m->create_dir_config)(p, NULL)

This means that both create_server_config and create_dir_config
function *are always* called on LoadModule, before module's
pre_config hook is called.

Is this a correct behavior?

Regards,
Mladen.

Re: LoadModule questions on WIN32

Posted by Mladen Turk <mt...@apache.org>.
Paul Querna wrote:
>>
>>proxy_module --> [P]
>>proxy_balancer_module --> [B]
>>
>>
>>1. [P] register_hooks
>>2. [P] create_server_config
>>3. [P] create_dir_config
>>4. [B] register_hooks
>>5. [P] pre_config
>>6. [B] pre_config
>>
> 
> [..snip..]
> 
> IMO, this sure sounds like a bug in the way the WINNT MPM operates. I
> believe it should be changed to match the same pattern as all the other
> MPMs.
>

Right. I came to the same conclusion :)

Do you know what would be the correct behavior?
I suppose:

LoadModule 1
register_hooks 1
...
LoadModule N
register_hooks N
...
pre_config 1
pre_config N
...
etc...


BTW, If I inside mod_so, comment the call to the:
ap_single_module_configure(cmd->pool, cmd->server, modp);

everything is working magically OK.
(Well at least for the default config).


Regards,
Mladen.







Re: LoadModule questions on WIN32

Posted by Paul Querna <ch...@force-elite.com>.
Mladen Turk wrote:
> Hi,
> 
> Since we have a problem with recent patched from Jim for
> loadbalancer, that basically core dumps WIN32 build, and
> I suppose other platforms are working OK, I've done some
> debugging adding traces to the various stages in module
> loading and initialization, so I have a question if this
> is correct behavior on all platforms.
> 
> 1. LoadModule order in conf file defined the module
>    loading order.
>    That is correctly handled.
> 
> 2. First thing called is register_hooks table.
>    Suppose that is correct too.
> 
> Now, I would expect that the third hook called is 'pre_config',
> but here is what happens for:
> 
> proxy_module --> [P]
> proxy_balancer_module --> [B]
> 
> 
> 1. [P] register_hooks
> 2. [P] create_server_config
> 3. [P] create_dir_config
> 4. [B] register_hooks
> 5. [P] pre_config
> 6. [B] pre_config
> 
[..snip..]

IMO, this sure sounds like a bug in the way the WINNT MPM operates. I
believe it should be changed to match the same pattern as all the other
MPMs.

-Paul

Re: LoadModule questions on WIN32

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Mladen Turk wrote:
> Hi,
> 
> Since we have a problem with recent patched from Jim for
> loadbalancer, that basically core dumps WIN32 build, and
> I suppose other platforms are working OK, ...

FYI - proxy_balancer test framework works flawlessly.  the proxy.t suite
dies at test #6 with absolutely no feedback.

The test looks borked, sending 100 CONTINUE with a Host: header, and
then no Host: header on the 200 OK result.  Still investigating.

Bill