You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2005/09/15 22:53:29 UTC
DO NOT REPLY [Bug 26686] -
ldap cache processing loop
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=26686>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=26686
lmeiners@cybsec.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|CLOSED |REOPENED
Resolution|WORKSFORME |
------- Additional Comments From lmeiners@cybsec.com 2005-09-15 22:53 -------
I'm using Apache 2.0.54 as a reverse proxy, and the hangs (as mentioned in the
first mail) keep ocurring.
I have been debugging with gdb and the process enters an infinite loop in lines
75,77,80,81 of httpd-2.0.54/srclib/apr-util/misc/apr_rmm.c, with values:
next = 14112
size = 32
blk->size = 0
blk->prev = 7720
blk->next = 14112
Here is the backtrace:
#0 0x40024023 in find_block_of_size (rmm=0x404d1008, size=32) at apr_rmm.c:75
#1 0x4002471f in apr_rmm_calloc (rmm=0x81df660, reqsize=32) at apr_rmm.c:305
#2 0x08080700 in util_ald_alloc (cache=0x404d1668, size=1078792200) at
util_ldap_cache_mgr.c:103
#3 0x08080cdb in util_ald_cache_insert (cache=0x404d1668, payload=0xbfffb680)
at util_ldap_cache_mgr.c:401
#4 0x0807ed89 in util_ldap_cache_checkuserid (r=0x827cd28, ldc=0x8228b50,
url=0xbfffb680 " �����'\b��'\b\202(V#�",
basedn=xxxxxxxx "dc=xx", scope=2, attrs=0x8221028, filter=0xbfffb720
"(&(objectClass=*)(uid=xxxxx))",
bindpw=0x827e1a2 "xxxxxx", binddn=xxxxxxx, retvals=0xbfffb718) at
util_ldap.c:950
#5 0x08081956 in mod_auth_ldap_check_user_id (r=0x827cd28) at mod_auth_ldap.c:360
#6 0x080d2376 in ap_run_check_user_id (r=0x827cd28) at request.c:70
#7 0x080d2c76 in ap_process_request_internal (r=0x827cd28) at request.c:217
#8 0x080ab179 in ap_process_request (r=0x827cd28) at http_request.c:247
#9 0x080a6cc9 in ap_process_http_connection (c=0x8272488) at http_core.c:251
#10 0x080c7206 in ap_run_process_connection (c=0x8272488) at connection.c:43
#11 0x080bb504 in child_main (child_num_arg=3) at prefork.c:610
#12 0x080bb630 in make_child (s=0x81a7f30, slot=1) at prefork.c:704
#13 0x080bb8b7 in perform_idle_server_maintenance (p=0x81a2798) at prefork.c:839
#14 0x080bbebe in ap_mpm_run (_pconf=0x0, plog=0x81e0890, s=0x0) at prefork.c:1040
#15 0x080c1688 in main (argc=3, argv=0xbfffda54) at main.c:618
#16 0x402b14a2 in __libc_start_main () from /lib/libc.so.6
I'm using the default values for the cache. As someone mentioned this seems an
apr bug, where do I report it?
I'm going to see what happens after disabling the cache but, for obvious
performance, reasons I would like help in fixing the bug to reenable chacheing.
Regards,
lmeiners >><at><< cybsec.com
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org