Re: Proposed Lua backport for 2.4
On 3/13/2013 1:12 PM, Daniel Gruno wrote: On 03/13/2013 08:39 PM, Gregg Smith wrote: On 3/13/2013 4:44 AM, Daniel Gruno wrote: On 03/13/2013 02:50 AM, Gregg Smith wrote: Hi Daniel, I'm seeing segfaults on that dreadful Windows OS when using LuaMapHandler& LuaRoot together. The backtrace was actually quite helpful :) It would appear that the bug (perhaps) pre-dates my work on mod_lua (or it could be something I've missed completely, who knows). I can see that vm_construct is creating, or attempting to create, a lua VM which returns a null pointer meaning that part failed, but it doesn't check whether the VM is null, making munge_path segfault. At the same time, the lifecycle_pool being passed is also NULL, which makes even less sense to me, since you can see in the backtrace that it wasn't null when it got passed to ap_lua_get_lua_state. Can you tell me which exact lua directives you used for this? which LuaScope, LuaCodeCache and so on? AddHandler lua-script .lua LuaMapHandler /testlua /usr/etc/lua/example.lua LuaRoot /usr/etc/lua Options All AllowOverride None Require all granted So since not specifically configured, the defaults of once and stat respectively. Regards, Gregg I am unable to get my own server to segfault, and I can't seem to find anything in the code that would cause the pool to suddenly become null. Your backtrace seems to indicate that your request calls: ap_lua_get_lua_state(apr_pool_t * lifecycle_pool=0x0258c0e8, ap_lua_vm_spec * spec=0x0258b658, request_rec * r=0x0258a120) which then calls: vm_construct(lua_State * * vm=0x036efdc0, void * params=0x0258b658, apr_pool_t * lifecycle_pool=0x) except lifecycle_pool never gets changed anywhere in the code, it's just passed straight through to vm_construct...so whatever made it turn into 0x0 is beyond my eyes to spot. If anyone else can spot something I'm missing, please do speak up, otherwise I'll probably chalk this one down to a Windows oddity. It was suggested to me a few days ago off list to give the old module a try pre r1200614. I did just that yesterday and it works and no segfaults. Just FYI. Regards, Gregg
Re: Proposed Lua backport for 2.4
On 03/13/2013 08:39 PM, Gregg Smith wrote: > On 3/13/2013 4:44 AM, Daniel Gruno wrote: >> On 03/13/2013 02:50 AM, Gregg Smith wrote: >>> Hi Daniel, >>> >>> I'm seeing segfaults on that dreadful Windows OS when using >>> LuaMapHandler& LuaRoot together. >>> >> The backtrace was actually quite helpful :) It would appear that the bug >> (perhaps) pre-dates my work on mod_lua (or it could be something I've >> missed completely, who knows). >> >> I can see that vm_construct is creating, or attempting to create, a lua >> VM which returns a null pointer meaning that part failed, but it doesn't >> check whether the VM is null, making munge_path segfault. At the same >> time, the lifecycle_pool being passed is also NULL, which makes even >> less sense to me, since you can see in the backtrace that it wasn't null >> when it got passed to ap_lua_get_lua_state. >> >> Can you tell me which exact lua directives you used for this? which >> LuaScope, LuaCodeCache and so on? > > AddHandler lua-script .lua > LuaMapHandler /testlua /usr/etc/lua/example.lua > LuaRoot /usr/etc/lua > > Options All > AllowOverride None > Require all granted > > > > So since not specifically configured, the defaults of once and stat > respectively. > > Regards, > Gregg I am unable to get my own server to segfault, and I can't seem to find anything in the code that would cause the pool to suddenly become null. Your backtrace seems to indicate that your request calls: ap_lua_get_lua_state(apr_pool_t * lifecycle_pool=0x0258c0e8, ap_lua_vm_spec * spec=0x0258b658, request_rec * r=0x0258a120) which then calls: vm_construct(lua_State * * vm=0x036efdc0, void * params=0x0258b658, apr_pool_t * lifecycle_pool=0x) except lifecycle_pool never gets changed anywhere in the code, it's just passed straight through to vm_construct...so whatever made it turn into 0x0 is beyond my eyes to spot. If anyone else can spot something I'm missing, please do speak up, otherwise I'll probably chalk this one down to a Windows oddity. With regards, Daniel.
Re: Proposed Lua backport for 2.4
On 3/13/2013 4:44 AM, Daniel Gruno wrote: On 03/13/2013 02:50 AM, Gregg Smith wrote: Hi Daniel, I'm seeing segfaults on that dreadful Windows OS when using LuaMapHandler& LuaRoot together. The backtrace was actually quite helpful :) It would appear that the bug (perhaps) pre-dates my work on mod_lua (or it could be something I've missed completely, who knows). I can see that vm_construct is creating, or attempting to create, a lua VM which returns a null pointer meaning that part failed, but it doesn't check whether the VM is null, making munge_path segfault. At the same time, the lifecycle_pool being passed is also NULL, which makes even less sense to me, since you can see in the backtrace that it wasn't null when it got passed to ap_lua_get_lua_state. Can you tell me which exact lua directives you used for this? which LuaScope, LuaCodeCache and so on? AddHandler lua-script .lua LuaMapHandler /testlua /usr/etc/lua/example.lua LuaRoot /usr/etc/lua Options All AllowOverride None Require all granted So since not specifically configured, the defaults of once and stat respectively. Regards, Gregg
Re: Proposed Lua backport for 2.4
On 03/13/2013 02:50 AM, Gregg Smith wrote: > Hi Daniel, > > I'm seeing segfaults on that dreadful Windows OS when using > LuaMapHandler & LuaRoot together. > Not to worry, I'm seeing seeing this on trunk as well, so it's not your > backport per se. > > Some likely useless info: > http://people.apache.org/~gsmith/httpd/segfault/mod_lua_map_handler_call_stack.txt > > > Cheers, > Gregg > The backtrace was actually quite helpful :) It would appear that the bug (perhaps) pre-dates my work on mod_lua (or it could be something I've missed completely, who knows). I can see that vm_construct is creating, or attempting to create, a lua VM which returns a null pointer meaning that part failed, but it doesn't check whether the VM is null, making munge_path segfault. At the same time, the lifecycle_pool being passed is also NULL, which makes even less sense to me, since you can see in the backtrace that it wasn't null when it got passed to ap_lua_get_lua_state. Can you tell me which exact lua directives you used for this? which LuaScope, LuaCodeCache and so on? With regards, Daniel.
Re: Proposed Lua backport for 2.4
Hi Daniel, I'm seeing segfaults on that dreadful Windows OS when using LuaMapHandler & LuaRoot together. Not to worry, I'm seeing seeing this on trunk as well, so it's not your backport per se. Some likely useless info: http://people.apache.org/~gsmith/httpd/segfault/mod_lua_map_handler_call_stack.txt Cheers, Gregg
Re: Proposed Lua backport for 2.4
On Mar 8, 2013, at 2:49 PM, Daniel Gruno wrote: > On 03/08/2013 08:22 PM, Jim Jagielski wrote: >> From what I can see, that's exactly what it does... >> >> I plan on testing this weekend. Daniel, do you have any >> testing suites you use? >> > I have some additions to the Perl framework we use, but that's mostly > for testing the LuaMapHandler (which no one uses*cough*). I was advised > not to push these changes into the test framework, as it'd break it (as > I understand it, we use it for 2.4 tests, not trunk tests), but once/if > the stuff gets backported, I'd be happy to put those tests into the > framework. Actually, we use it for all tests. The framework is smart enough, if the tests are written correctly, to only run those tests which are applicable to a certain version or version level. The breakage is only when tests are added which test trunk additions but the need_min_apache_version(*) rulz aren't used.
Re: Proposed Lua backport for 2.4
On 03/08/2013 11:18 PM, Gregg Smith (gsmith) wrote: > On 3/8/2013 11:49 AM, Daniel Gruno wrote: >> for testing the LuaMapHandler (which no one uses*cough*). > > I tried a week or two ago after finding an example using it, then > quickly found out it had disappeared thanks to a commit logged "remove > some debug logging which snuck in," which snuck out a lot more than > debug logging, then happily backported. > > I was going to bring it up, but your post AC email came through. > > Gregg > > > > Hah, yes, I had a talk with Brian at ApacheCon about the LuaMapHandler, and we were both under the impression, that we had made the code ourselves, so somehow it must've vanished from trunk before I started working on mod_lua. But now it's there (again), and I can see some potential in it for fx. unit testing - and perhaps more stuff once I sit down and have a think about it. One could fx map a controlled set of functions to a single file by doing: LuaMapHandler ^/(foo|bar|baz)$ /www/foo/script.lua $1_handler With regards, Daniel.
Re: Proposed Lua backport for 2.4
On 3/8/2013 11:49 AM, Daniel Gruno wrote: for testing the LuaMapHandler (which no one uses*cough*). I tried a week or two ago after finding an example using it, then quickly found out it had disappeared thanks to a commit logged "remove some debug logging which snuck in," which snuck out a lot more than debug logging, then happily backported. I was going to bring it up, but your post AC email came through. Gregg
Re: Proposed Lua backport for 2.4
On 03/08/2013 08:22 PM, Jim Jagielski wrote: > From what I can see, that's exactly what it does... > > I plan on testing this weekend. Daniel, do you have any > testing suites you use? > Okay, I'm being told I should stop being on Portland time and get back to my usual day rhythm, so I'll cut the testing short and pick it up again tomorrow. What I've been able to piece together so far is at http://www.humbedooh.com/apache/mod_lua_test.lua (You can see a test of this at http://apaste.info/mod_lua_test.lua ) it's a simple test that runs some functions (as a web page), compares the result with what's expected and...yada yada yada. Since a lot of the new functions/features are best tested with the framework, I'll look into adding some more comprehensive testing via just that, either on Saturday or Sunday. With regards, Daniel.
Re: Proposed Lua backport for 2.4
On Fri, 8 Mar 2013, Daniel Gruno wrote:
On 03/08/2013 08:22 PM, Jim Jagielski wrote:
From what I can see, that's exactly what it does...
I plan on testing this weekend. Daniel, do you have any
testing suites you use?
I have some additions to the Perl framework we use, but that's mostly
for testing the LuaMapHandler (which no one uses*cough*). I was advised
not to push these changes into the test framework, as it'd break it (as
I understand it, we use it for 2.4 tests, not trunk tests), but once/if
the stuff gets backported, I'd be happy to put those tests into the
framework.
It is possible to make tests run only with trunk using
need_min_apache_version('2.5'). If that's the only problem, you should
commit those tests you have.
Re: Proposed Lua backport for 2.4
On 03/08/2013 08:22 PM, Jim Jagielski wrote: > From what I can see, that's exactly what it does... > > I plan on testing this weekend. Daniel, do you have any > testing suites you use? > I have some additions to the Perl framework we use, but that's mostly for testing the LuaMapHandler (which no one uses*cough*). I was advised not to push these changes into the test framework, as it'd break it (as I understand it, we use it for 2.4 tests, not trunk tests), but once/if the stuff gets backported, I'd be happy to put those tests into the framework. As for the rest, my tests have primarily been the actual work I have made for the ASF and for myself. However, as there are now people wanting to test the API, I'll sit down tonight and work out a small test suite, so people can see that the stuff works, and hopefully also get some pointers on how to actually use mod_lua to its fullest. I'll let you know as soon as I've come up with something worth sharing. In the meantime, feel free to poke around the source code for fx. modules.apache.org or paste.apache.org (both are in infra's svn repo, https://svn.apache.org/repos/infra/infrastructure/trunk/projects/ ) and see what I'm using there. So, stay tuned, and I'll probably have something for you in a couple of hours. With regards, Daniel.
Re: Proposed Lua backport for 2.4
From what I can see, that's exactly what it does... I plan on testing this weekend. Daniel, do you have any testing suites you use? On Mar 8, 2013, at 1:12 PM, Guenter Knauf wrote: > Am 08.03.2013 17:32, schrieb Daniel Gruno: >> I've just proposed a rather large backport of all the Lua stuff we have >> in trunk, I hope you'll take a look at it. > to me it seems to make more sense to just copy over the trunk version to 2.4 > branch ... > > Gün. > >
Re: Proposed Lua backport for 2.4
Am 08.03.2013 19:15, schrieb Daniel Gruno: On 03/08/2013 07:12 PM, Guenter Knauf wrote: Am 08.03.2013 17:32, schrieb Daniel Gruno: I've just proposed a rather large backport of all the Lua stuff we have in trunk, I hope you'll take a look at it. to me it seems to make more sense to just copy over the trunk version to 2.4 branch ... Gün. That is also what the proposed backport does - it's one big diff of what separates 2.4 and trunk, hence the proposal saying 'sync' ;) I'm sorry if that was unclear from my email. naa, your mail was clear so far, but I saw the backport proposal with the bunch of single links :-P but now I think thats only to make clear on what commits the sync is based ... Gün.
Re: Proposed Lua backport for 2.4
On 03/08/2013 07:12 PM, Guenter Knauf wrote: > Am 08.03.2013 17:32, schrieb Daniel Gruno: >> I've just proposed a rather large backport of all the Lua stuff we have >> in trunk, I hope you'll take a look at it. > to me it seems to make more sense to just copy over the trunk version to > 2.4 branch ... > > Gün. > > That is also what the proposed backport does - it's one big diff of what separates 2.4 and trunk, hence the proposal saying 'sync' ;) I'm sorry if that was unclear from my email. With regards, Daniel.
Re: Proposed Lua backport for 2.4
Am 08.03.2013 17:32, schrieb Daniel Gruno: I've just proposed a rather large backport of all the Lua stuff we have in trunk, I hope you'll take a look at it. to me it seems to make more sense to just copy over the trunk version to 2.4 branch ... Gün.
Proposed Lua backport for 2.4
Hi folks, I've just proposed a rather large backport of all the Lua stuff we have in trunk, I hope you'll take a look at it. Basically, this is a sync between trunk and 2.4, which will bring the LuaCodeCache, the LuaScope server [min [max], Lua input/output filters, LuaMapHandler as well as the bazillion new functions (such as regex support, stat(), scoreboard features, base64/md5/sha1 digests etc) and multipart form data reading into the 2.4 branch. I feel this will be a great addition to the folks already using mod_lua, so they can truly benefit from what Lua has to offer people developing stuff for httpd, whether it be hooks or web scripts. I've tested the trunk version of mod_lua on all of my servers for a good deal of time now, and I haven't run across any problems with trunk as it is today, so I'd like for us to backport these features (stefan and I did quite a bit of cleanup on the whole mess back in December), preferably in one big bit, as the various feautures are so intertwinced, it makes little sense to try to backport each chunk separately. FYI, this version of mod_lua also runs on modules.apache.org and paste.apache.org, so far without any signs of trouble ;) With regards, Daniel.
