https://issues.apache.org/bugzilla/show_bug.cgi?id=52779
--- Comment #1 from Dick Snippe <[email protected]> --- I just replicated this bug. The segfault is caused by cleanup_lua getting passed a NULL pointer; this NULL pointer is passed to lua_close(NULL), which tries to dereference is which cases a segfault. So how can cleanup_lua be passed a NULL pointer? Here is where it gets weird: The NULL pointer stems from ap_lua_get_lua_state where apr_pool_userdata_set is called with L==NULL. Now the weird thing is that L appears to be filled in slightly later. I added some debug code to print the value of L returned by vm_construct if(L==NULL) { ap_log_perror(APLOG_MARK, APLOG_DEBUG, 0, lifecycle_pool, APLOGNO(01483) "creating lua_State with file %s", spec->file); /* not available, so create */ if(vm_construct((void **)&L, spec, lifecycle_pool) == APR_SUCCESS) { ap_log_perror(APLOG_MARK, APLOG_DEBUG, 0, lifecycle_pool, APLOGNO(01483) "call apr_pool_userdata_set with %x", (unsigned int) L); ap_log_perror(APLOG_MARK, APLOG_DEBUG, 0, lifecycle_pool, APLOGNO(01483) "call apr_pool_userdata_set with %x", (unsigned int) L); apr_pool_userdata_set(L, spec->file, cleanup_lua, lifecycle_pool); } note that both ap_log_perror calls are identical, however the output isn't identical: [Tue Jun 12 22:00:10.169038 2012] [lua:debug] [pid 25340:tid 1136863568] lua_vmprep.c(415): AH01483: creating lua_State with file /home/beheer/dick/apache/lua/luatest.lua [Tue Jun 12 22:00:10.169696 2012] [lua:debug] [pid 25340:tid 1136863568] lua_vmprep.c(365): AH01481: loading lua file /home/beheer/dick/apache/lua/luatest.lua [Tue Jun 12 22:00:10.169905 2012] [lua:debug] [pid 25340:tid 1136863568] lua_vmprep.c(420): AH01483: call apr_pool_userdata_set with 0 [Tue Jun 12 22:00:10.169924 2012] [lua:debug] [pid 25340:tid 1136863568] lua_vmprep.c(423): AH01483: call apr_pool_userdata_set with 2224bc0 I assume that without the debug code the first (NULL) value is passed to apr_pool_userdata_set, causing havoc. As to why L==NULL at the firs reference but not on subsequent references I have no idea. A bad compiler optimization perhaps? That might explain why not everybody can replicate this bug. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
