https://issues.apache.org/bugzilla/show_bug.cgi?id=52921
--- Comment #5 from Konstantin Kolinko <knst.koli...@gmail.com> 2012-03-16 23:41:19 UTC --- Reviewing diff of current native/apache-2.0/mod_jk.c against r1142157 (aka 1.2.32 tag) That is: [1] http://svn.apache.org/viewvc/tomcat/jk/trunk/native/apache-2.0/mod_jk.c?r1=1240904&r2=1142157&diff_format=h The request-specific configuration structure was changed from (rule_extension_t *) to new structure (jk_request_conf_t *). That was done in r1187906 Looking at the hook methods in mod_jk.c that access jk_request_conf_t: 1. jk_translate Does palloc of new instance unconditionally 2. jk_map_to_storage Checks for NULL and conditionally does palloc of new instance. 3. request_log_transaction Checks for NULL and returns DECLINED if it is null 4. jk_handler and init_ws_service (supplementary method called from jk_handler) Access the structure without checking it for NULL. Those are lines @r1293818: 805, 807; 2575, 2577; 2603, 2605; 2625, 2627 I think that jk_handler method should get the jk_request_conf_t instance once somewhere near the top of the method and check it for being NULL. There are 3 possible ways to react if it is NULL: a) return DECLINED, b) palloc a new instance like jk_map_to_storage does. c) skip the code that accesses the structure + jk_request_conf_t *rconf = ap_get_module_config(r->request_config, &jk_module); + if (rconf == NULL) { + jk_request_conf_t *rconf = apr_palloc(r->pool, sizeof(jk_request_conf_t)); + rconf->jk_handled = JK_FALSE; + rconf->rule_extensions = NULL; + ap_set_module_config(r->request_config, &jk_module, rconf); + } + -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
