Note the stack trace below was generated with 2.0.51's global mutex
changes removed.
A crash still occurs with a zero sized cache with the global mutex
changes in place, but I believe it is from a null mutex, not a null
cache hash function entry.
--
Jess Holle
Jess Holle wrote:
Here you go:
00000000()
util_ald_cache_fetch(util_ald_cache * 0x00a02cb8, void * 0x04c6de84)
line 358 + 12 bytes
util_ldap_cache_checkuserid(request_rec * 0x6fb51341,
util_ldap_connection_t * 0x00a5cdb0, const char * 0x00a02cf0, const
char * 0x00880db0, int 9487736, char * * 0x00000002, const char *
0x00000000, const char * 0x04c6def4, const char * * 0x00a5eede, const
char * * * 0x04c6dee8) line 785 + 22 bytes
mod_auth_ldap_check_user_id(request_rec * 0x6ff110bf) line 333
LIBHTTPD! 6ff110bf()
Note that none of the line numbers quite match as I've added comments
in my source. Thus the util_ald_cache_fetch() line is:
hashval = (*cache->hash)(payload) % cache->size;
While the util_ldap_cache_checkuserid() line is:
search_nodep =
util_ald_cache_fetch(curl->search_cache,
&the_search_node);
I was just about to patch around this by check cache->hash for null
and returning null in this case from util_ald_cache_fetch(), but I'm
all ears for a better fix. I'm also all ears for a fix to the hang --
perhaps I can cull out a stack dump for that too...
--
Jess Holle
Graham Leggett wrote:
Jess
Holle
wrote:
I reverted to the mod_auth_ldap and
util_ldap
(aka mod_ldap) from 2.0.50 and this fixed the hangs and the crash when
the cache is disabled by zero-sizing everything. Therefore APR fixes,
etc, are not the issue -- util_ldap itself is (as mod_auth_ldap did not
change).
Is it possible to get a stack trace from the crash?
Regards,
Graham
--
|
