William A. Rowe, Jr. wrote:
At 01:33 PM 9/20/2004, Jess Holle wrote:
Brad Nicholes wrote:
I'm still wondering if we shouldn't just stick with the local
read/write
lock on Windows and other single child MPMs (NetWare?) as this should
allow better throughpu
Even after all my patches, I still get a bus error and core dump on the
first LDAP authentication request on Solaris 8 with worker MPM and an
active shared memory LDAP cache. [This is with iPlanet LDAP SDK 5.08,
though I doubt that matters.]
I've run out of time to look into this further. Mor
At 01:33 PM 9/20/2004, Jess Holle wrote:
>Brad Nicholes wrote:
>>>
>>>I'm still wondering if we shouldn't just stick with the local
>>>read/write
>>>lock on Windows and other single child MPMs (NetWare?) as this should
>>>allow better throughput in such cases and yet be safe, right? In
>>>fact,
Brad Nicholes wrote:
I'm still wondering if we shouldn't just stick with the local
read/write
lock on Windows and other single child MPMs (NetWare?) as this should
allow better throughput in such cases and yet be safe, right? In
fact,
Actually on NetWar
>I'm still wondering if we shouldn't just stick with the local
read/write
>lock on Windows and other single child MPMs (NetWare?) as this should
>allow better throughput in such cases and yet be safe, right? In
fact,
Actually on NetWare this is a non-issue. On NetWare everything is
global (me
Sorry. One last post...
It seems that at least on Windows if I place
SetHandler ldap-status
too early in the configuration Apache crashes on shutdown.
Specifically, if I place it in front of my mod_deflate configuration
(similar to that in documentation), it will crash on shutdown with:
Jess Holle wrote:
Jess Holle wrote:
Here's one final patch to fix the global mutex crash when the global
mutex is never allocated due to disabled/empty caches.
I would really like some clarity as to whether:
We should just stick with the single-process read/w
Jess Holle wrote:
Here's one final patch to fix the global mutex crash when the global
mutex is never allocated due to disabled/empty caches.
I would really like some clarity as to whether:
We should just stick with the single-process read/write lock
for
single-worker MPMs. It
Here's one final patch to fix the global mutex crash when the global
mutex is never allocated due to disabled/empty caches.
I would really like some clarity as to whether:
We should just stick with the single-process read/write lock for
single-worker MPMs. It would really seem so.
Whethe
Sorry for the chattiness of my solution process. I've tested and these
fixes do apply with the global mutex changes *except* when one disables
caches by sizing them all to 0, Apache will crash on the first
authentication request when the global mutexes are used! This needs to
be fixed!
I've
Here's a fixed LDAP purge routine which works great in my testing (with
cache sizes of 8, 100, 1000, and 2150 and 2500 unique user logins
repeated 3 times each). [No, I haven't produced a diff as I have
pieces of util_ldap from various CVS levels at this point.]
Essentially I added all the lo
Another dumb question:
On Windows since there is only one child process, wouldn't it make sense
to stick with the read/write locks and not move to a global mutex?
In the multi-child mpms, the global mutex is obviously required, of course.
--
Jess Holle
Graham Leggett wrote:
Jess Holle wrote:
I now see what's wrong with the LDAP cache purge -- it does not fix
up the 'next' pointers and/or cache->node[i] pointers when removing
entries -- and thus cannot hope to work.
Unfortunately, my fixes for this are still falling short, but I
thought I'd pa
Jess Holle wrote:
I now see what's wrong with the LDAP cache purge -- it does not fix up
the 'next' pointers and/or cache->node[i] pointers when removing entries
-- and thus cannot hope to work.
Unfortunately, my fixes for this are still falling short, but I thought
I'd pass this along.
Looking
I now see what's wrong with the LDAP cache purge -- it does not fix up
the 'next' pointers and/or cache->node[i] pointers when removing entries
-- and thus cannot hope to work.
Unfortunately, my fixes for this are still falling short, but I thought
I'd pass this along.
--
Jess Holle
Graham Leggett wrote:
Jess Holle wrote:
Just a note: this was enough to fix the problem without the global
mutexes present -- I've not tested again with the mutexes present as
I want to get to the bottom of the cache overflow crashes first if I
can.
The fix should still go in anyway as leaving
Jess Holle wrote:
Just a note: this was enough to fix the problem without the global
mutexes present -- I've not tested again with the mutexes present as I
want to get to the bottom of the cache overflow crashes first if I can.
The fix should still go in anyway as leaving this uninitialized will
Graham Leggett wrote:
Jess Holle wrote:
Okay, the cause of this issue is now clear:
util_ald_create_caches() does not set 'newcurl' to anything when any
of the caches are null, which they all are when they're sized at
zero.
The fix is also simple: add an 'else newcurl = NULL;' after the '
Jess Holle wrote:
Okay, the cause of this issue is now clear:
util_ald_create_caches() does not set 'newcurl' to anything when any
of the caches are null, which they all are when they're sized at zero.
The fix is also simple: add an 'else newcurl = NULL;' after the 'if'
block in this routi
Okay, the cause of this issue is now clear:
util_ald_create_caches() does not set 'newcurl' to anything
when any of the caches are null, which they all are when they're sized
at zero.
The fix is also simple: add an 'else newcurl = NULL;' after the 'if'
block in this routine.
[This really driv
Jess Holle wrote:
Here you go:
()
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, c
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 y
Here you go:
()
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 * * 0x0002, const c
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).
I now pl
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 pos
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).
I now plan to look for sou
William A. Rowe, Jr. wrote:
At 08:54 AM 9/17/2004, Jess Holle wrote:
... given the security and non-LDAP fixes in 2.0.51, I am now left pondering whether I should move try backing the LDAP modules back to 2.0.50 while keeping all other 2.0.51 code. Ideas?
All in all
At 08:54 AM 9/17/2004, Jess Holle wrote:
>... given the security and non-LDAP fixes in 2.0.51, I am now left pondering whether
>I should move try backing the LDAP modules back to 2.0.50 while keeping all other
>2.0.51 code. Ideas?
>All in all, LDAP does not appear to be a happy camper on 2.0.51
One small correction:
When I remove the global mutex stuff I no longer have the case where
both the worker and parent processes crash, so that's another
improvement on Windows. Unfortunately, I still have the case where
Apache hangs, however.
--
Jess Holle
Jess Holle wrote:
Working on a wild h
Working on a wild hunch, I backed util_ldap source down to right before
the global mutex stuff went in -- as that should not be necessary with a
single child process anyway, right?
This fixed the crash on shutdown -- but that's all.
I'm going to try the 2.0.50 util_ldap sources with everything e
one possibility is to apply the security patches you need to 2.0.50
see http://apache.towardex.com/httpd/patches/apply_to_2.0.50/
the descriptions of the vulnerabilities at http://httpd.apache.org/
indicate which components are affected; note that CAN-2004-0786
applies to all configurations; I ha
31 matches
Mail list logo
