Luaproc

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Luaproc

Ken Smith-2
I excitedly read the Luaproc paper:

http://www.inf.puc-rio.br/~roberto/docs/ry08-05.pdf

and decided to try it.  I've run into some trouble.  First my environment.

Lua 5.1.4-2 (built as C++)
GCC 4.0
Luaproc-1.0b1 (built as C++)
Mac OS X 10.6.3 (Darwin 10.3.0)

Firstly, I ran into a couple issues building Luaproc.  On OS X,
/usr/include/pthread.h includes a file called sched.h so I had to
rename Luaproc's sched.h to something else.  Also, because I built Lua
as C++, I needed to build Luaproc as C++ so I had to extern "C"
luaopen_luaproc.  Finally, I had to add -bundle -undefined
dynamic_lookup to the link per
http://lua-users.org/wiki/BuildingModules despite that page's own
indication to the contrary.

Once that was up and running, I wrote this into experiment.lua:
require "luaproc"
EOF

This segfaults:
(gdb) run ../experiment.lua
Starting program:
/Users/ken/Development/External_SDKs/lua/built_libs/bin/lua
../experiment.lua
Reading symbols for shared libraries +++.. done
Reading symbols for shared libraries . done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0006d164
[Switching to process 41790]
0x94222d9f in _pthread_cond_wait ()
(gdb) bt
#0  0x94222d9f in _pthread_cond_wait ()
#1  0x9426b42f in pthread_cond_wait ()
#2  0x0006a91d in ?? ()
#3  0x94222a19 in _pthread_start ()
#4  0x9422289e in thread_start ()

If I change experiment.lua to this:
require "luaproc"

luaproc.exit()
EOF

It exits normally.  For now, I'll take care to give Luaproc a chance
to clean up by always calling exit() but I thought the developers
would like to know of this behavior.  Please let me know if you would
like more information.

   Regards,
   Ken
Reply | Threaded
Open this post in threaded view
|

Re: Luaproc

Alexandre Skyrme-2
Ken Smith <kgsmith <at> gmail.com> writes:
> Firstly, I ran into a couple issues building Luaproc.  On OS X,
> /usr/include/pthread.h includes a file called sched.h so I had to
> rename Luaproc's sched.h to something else.  Also, because I built Lua
> as C++, I needed to build Luaproc as C++ so I had to extern "C"
> luaopen_luaproc.  Finally, I had to add -bundle -undefined
> dynamic_lookup to the link per
> http://lua-users.org/wiki/BuildingModules despite that page's own
> indication to the contrary.

greetings ken,

first, i´m glad you decided to try luaproc out.

we already had at least one report about problems with include files when
building on mac. i'll be looking into that issue.

> Once that was up and running, I wrote this into experiment.lua:
> require "luaproc"
> EOF
>
> This segfaults:
> If I change experiment.lua to this:
> require "luaproc"
>
> luaproc.exit()
> EOF
>
> It exits normally.  For now, I'll take care to give Luaproc a chance
> to clean up by always calling exit() but I thought the developers
> would like to know of this behavior.  Please let me know if you would
> like more information.

that is odd. calling luaproc.exit() is required just to ensure all workers have
finished executing before exiting the main thread. so, not calling it should
simply mean you risk having the main thread exit before workers have finished
executing. i don't think it should segfault. i'll try to get my hands on a mac
in order to build luaproc as you described and investigate the issue.

i'd be grateful if you could post any further information you might find
relevant to reproduce this condition.

--alexandre



Reply | Threaded
Open this post in threaded view
|

Re: Luaproc

Bruno Silvestre-2
On Thu, Jul 15, 2010 at 6:04 PM, Alexandre Skyrme
<[hidden email]> wrote:
>
> i'd be grateful if you could post any further information you might find
> relevant to reproduce this condition.
>

Same here...

Lua 5.1.4
GCC 4.2.1
Luaproc-1.0b1
Mac OS X 10.6.4

-- Core dump #1

$ gdb lua core.1189
[...]
#0  0x00007fff841bd286 in szone_malloc_should_clear ()
(gdb) thread 1
[Switching to thread 1 (core thread 0)]
0x00007fff841bd286 in szone_malloc_should_clear ()
(gdb) bt
#0  0x00007fff841bd286 in szone_malloc_should_clear ()
#1  0x00007fff841bcf0a in malloc_zone_malloc ()
#2  0x00007fff841cd039 in realloc ()
#3  0x000000010000b260 in luaM_realloc_ ()
#4  0x000000010000ef0e in luaS_newlstr ()
#5  0x0000000100002c37 in lua_pushlstring ()
#6  0x0000000100017155 in io_noclose ()
#7  0x0000000100017e9b in io_gc ()
#8  0x0000000100007922 in luaD_precall ()
#9  0x0000000100007d5e in luaD_call ()
#10 0x000000010000963e in GCTM ()
#11 0x0000000100009be8 in luaC_callGCTM ()
#12 0x0000000100007467 in luaD_rawrunprotected ()
#13 0x000000010000e880 in lua_close ()
#14 0x0000000100001564 in main ()
(gdb) thread 2
[Switching to thread 2 (core thread 1)]
0x000000010007d01a in ?? ()
(gdb) bt
#0  0x000000010007d01a in ?? ()
Cannot access memory at address 0x10007d01a
#1  0x00007fff841f2456 in _pthread_start ()
#2  0x00007fff841f2309 in thread_start ()


-- Core dump #2

$ gdb lua core.1227
[...]
#0  0x00000001000093ce in sweeplist ()
(gdb) thread 1
[Switching to thread 1 (core thread 0)]
0x00000001000093ce in sweeplist ()
(gdb) bt
#0  0x00000001000093ce in sweeplist ()
#1  0x00000001000094f7 in luaC_freeall ()
#2  0x000000010000e7af in close_state ()
#3  0x0000000100001564 in main ()
(gdb) thread 2
[Switching to thread 2 (core thread 1)]
0x000000010007d01a in ?? ()
(gdb) bt
#0  0x000000010007d01a in ?? ()
Cannot access memory at address 0x10007d01a
#1  0x00007fff841f2456 in _pthread_start ()
#2  0x00007fff841f2309 in thread_start ()

cheers
--
bruno
Reply | Threaded
Open this post in threaded view
|

Re: Luaproc

Ken Smith-2
In reply to this post by Alexandre Skyrme-2
On Thu, Jul 15, 2010 at 2:04 PM, Alexandre Skyrme
<[hidden email]> wrote:

> i'd be grateful if you could post any further information you might find
> relevant to reproduce this condition.

I will gladly post any new information as I get it.

One thing though that had me considering the alternatives is the fact
that the main process can't participate in message passing, only child
processes may pass messages to each other.  This architecture doesn't
work for me because I have a lot of C++ code exposed to the primary
Lua process using Luabind.  The child processes don't get this
binding.

Why does Luaproc prevent the primary Lua process to participate in
message passing?

In my application, I basically want to spawn a Lua process sandbox to
deal with some end user code.  As such, I want to remove global
symbols that expose potential vulnerabilities.  I have read the advice
on the wiki about how to do this and I believe I can accomplish this
with Luaproc.  And the reason I want to run this concurrently is so
that I can limit the amount of time the process has to accomplish its
task and end it prematurely if necessary.


My team had difficulty building Lanes on all the platforms we care
about so I have presently resigned myself to rolling my own concurrent
sandbox using boost::packaged_task around a fresh sandbox instance of
our Lua interpreter wrapper object.  I'd be happy to hear suggestions
for alternate solutions.

   Ken