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_ldap crash on exit (found why)
Date Sun, 23 Oct 2005 14:05:43 GMT
Vadim Chekan wrote:
> httpd version: current/trunk (2.2?)
> Platform: win xp pro SP2
> 
> I built Apache, added
> LoadModule ldap_module modules/mod_ldap.so
> LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
> ...
> LDAPSharedCacheFile "c:\ldap.cache"
> 
> and this causes crash on exit. The crash happends at util_ldap_cache_mgr.c:
> util_ald_destroy_cache(). It attempts to free() a node with some
> garbage address.
> After some investigation I noticed that address of cache->nodes
> changes between process start and process ends.
> 
> To make long story short:
> st->cache is allocated in shared memory.
> cache->nodes is also allocated in shared memory.
> Let's say parent process creates cache and nodes. Then parent executes
> cache->nodes = ShmAllocate(...);
> 
> The child process starts. It attach to shared memory and do the same,
> allocate and, attention:
> cache->nodes = ShmAllocate(...);

Yes - on Win32 this is an 'attach'...

> But as soon as this memory is shared, addres cache->nodes for child is
> different from parent. So child overrites parents cache->nodes!

There are raw pointers in the shm?  Well, in a fork() that's expected, but
in attached shared memory, that's an invalid assumption.  All 'pointers'
within a shm must be an off_t from the shm base and dereferenced relative
to the client's base address mapping.

> Then, on exit parent attempts to release an address that is
> meaningless in its process space.

That indicates a lack of symmetry.

> Another thing I don't like too much is that both, parent and children
> will call apr_shm_destroy()
> I think correct way to do it would be children call detach() and only
> parent calls destroy()

Not an issue, the shm isn't destroyed until the last reference is released.

> BTW: could comebody explain, how modules configs are shared between
> processes? Is an instance created by each process? Main process shares
> them with children via shared memory?

On unix, it's already set up prior to fork(), on Win32 the config is passed
from the parent->child and set up in that local child process.  It's not
'shared memory' - even on unix the child's copy is local to that process.

Therefore the only way to share info (e.g. caches and scoreboard) is to
declare shared memory sections.

Bill

Mime
View raw message