httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 52779] mod_lua segfaults
Date Tue, 12 Jun 2012 20:13:14 GMT

--- Comment #1 from Dick Snippe <> ---
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,
                      "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,
                      "call apr_pool_userdata_set with %x", (unsigned int) L);
                ap_log_perror(APLOG_MARK, APLOG_DEBUG, 0, lifecycle_pool,
                      "call apr_pool_userdata_set with %x", (unsigned int) L);


note that both ap_log_perror calls are identical, however the output isn't

[Tue Jun 12 22:00:10.169038 2012] [lua:debug] [pid 25340:tid 1136863568]
lua_vmprep.c(415): AH01483: creating lua_State with file
[Tue Jun 12 22:00:10.169696 2012] [lua:debug] [pid 25340:tid 1136863568]
lua_vmprep.c(365): AH01481: loading lua file
[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:
For additional commands, e-mail:

View raw message