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=43025>. 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=43025 Summary: Size of GDBM value not calculated or stored, potentially yielding excessive memory usage with RewriteMaps Product: Apache httpd-2 Version: 2.2.4 Platform: Other OS/Version: AIX Status: NEW Severity: normal Priority: P2 Component: Core AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] The RETURN_DATUM macro of srclib/apr-util/dbm/apr_dbm_gdbm.c copies the fetched datum structure, which will constitute the "result" of a e.g. a GDBM RewriteMap lookup. However, no calculations or settings of the dsize member of the apr_datum_t structure appears to be performed or stored! This has the following implication: When mod_rewrite's do_expand() calls apr_pstrmemdup() in order to create a "working copy" of the fetched GDBM value for a key, apr_pstrmemdup() is fed the dsize value of the apr_datum_t structure -- which is uninitialized and hence incorrect -- potentially causing excessive memory usage. In our case, one such rewrite consumes approximately 800 MB of memory because of the bogus dsize value: ---8<--- (gdb) step 108 in strings/apr_strings.c (gdb) where #0 apr_pstrmemdup (a=0x305c9880, s=0x30556d58 "wiki", n=808929792) at strings/apr_strings.c:108 #1 0xd8c945d0 in do_expand ( input=0x303cab78 "${itwiki_pag\e_\exists:/|NONE}", ctx=0x3055e818) at mod_rewrite.c:1308 #2 0xd8c9557c in apply_rewrite_list (r=0x3055d238, rewriterules=0x303691e0, perdir=0x0) at mod_rewrite.c:3493 #3 0xd8c96084 in hook_uri2file (r=0x3055d238) at mod_rewrite.c:4225 #4 0x100226e0 in ap_run_translate_name (r=0x3055d238) at request.c:66 #5 0x10025678 in ap_process_request_internal (r=0x3055d238) at request.c:141 #6 0x10038518 in ap_process_request (r=0x3055d238) at http_request.c:256 #7 0x1003792c in ap_process_http_connection (c=0x3054e110) at http_core.c:184 #8 0x10034ce8 in ap_run_process_connection (c=0x3054e110) at connection.c:43 #9 0x1002f240 in child_main (child_num_arg=811374720) at prefork.c:640 #10 0x1002f458 in make_child (s=0x30003680, slot=0) at prefork.c:680 #11 0x10030090 in ap_mpm_run (_pconf=0x2ff22884, plog=0x30556d58, s=0x300195c0) at prefork.c:956 #12 0x100010a4 in main (argc=7, argv=0x2ff22a40) at main.c:717 --->8--- Notice n=808929792 (bytes). When stepping further, that amount of memory gets allocated... Suggested fix: Something along the lines of RETURN_DATUM in srclib/apr-util/dbm/apr_dbm_sdbm.c where dsize gets set. Perhaps: #define RETURN_DATUM(poutput, rd) (*(poutput) = *(apr_datum_t *)&(rd) ; (poutput)->dsize = strlen((poutput)->dptr)) ...although you're better at that. Best regards, Björn -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
