#bitfighter IRC Log

IRC Log for 2012-04-11

Timestamps are in GMT/BST.

00:32:52 BFLogBot - Commit 40b254a6084b | Author: watusim...@bitfighter.org | Log: Rename method printToOglConsole to printToConsole (could affect some lua scripts)
00:32:54 BFLogBot - Commit adcc92474cb1 | Author: watusim...@bitfighter.org | Log: More efficient script startup, other cleanup and reorg
00:32:55 BFLogBot - Commit 470be8015578 | Author: watusim...@bitfighter.org | Log: Merge
00:41:06 Watusimoto Quit (Ping timeout: 246 seconds)
03:00:36 Heyub Quit (Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/)
03:40:09 raptor has joined
03:42:03 raptor Quit (Client Quit)
04:21:57 raptor has joined
04:21:57 ChanServ sets mode +o raptor
04:22:02 raptor good evening
04:49:41 raptor Quit (Quit: Page closed)
05:38:34 kodaws has joined
08:09:14 watusimoto has joined
08:09:15 ChanServ sets mode +o watusimoto
08:12:14 sam686 Quit (Ping timeout: 245 seconds)
09:51:47 Watusimoto_ has joined
10:45:46 Watusimoto_ Quit (Ping timeout: 252 seconds)
11:24:39 kodaws Quit (Ping timeout: 240 seconds)
12:53:06 Watusimoto_ has joined
14:29:12 Watusimoto_ Quit (Ping timeout: 246 seconds)
14:41:14 raptor has joined
14:41:14 ChanServ sets mode +o raptor
14:41:27 raptor good day
14:50:15 raptor changes topic to 'Bitfighter 017a released!: http://bitfighter.org/downloads'
14:50:19 raptor has left
14:50:21 raptor has joined
14:50:21 ChanServ sets mode +o raptor
14:51:51 watusimoto hi
14:51:58 raptor hello
14:52:37 raptor i haven't tested your latest changes yet..
15:01:12 watusimoto that's ok.-- neither have I
15:01:16 watusimoto ok, off to german class
15:01:18 raptor ha
15:01:20 raptor later
15:02:07 raptor seg fault
15:02:24 raptor probably need to copy over new scripts..
15:03:58 raptor valid segfault:  http://pastie.org/3768556
15:04:27 BFLogBot - Commit a9616c2d3f40 | Author: buckyballreaction | Log: Remove s_bot from exe folder (again) since it is in resources
15:41:14 raptor second valid segfault:  http://pastie.org/3768782
15:41:35 raptor first is starting a level with a levelgen; second is with adding bot to a normal level
16:30:22 watusimoto any invalid segfaults?
16:30:34 raptor hehe
16:30:46 raptor just got those two..  and i made sure to copy over the new resources
16:30:56 raptor and clean compile
16:31:30 watusimoto levelgens not yet working!
16:31:50 watusimoto lets look at the second
16:32:22 raptor both have to do with lua environment set, i think
16:32:47 watusimoto yes
16:32:50 watusimoto the second
16:32:54 watusimoto void LuaScriptRunner::setEnvironment(const char *environmentName, bool environmentIsGlobal)
16:32:54 watusimoto {
16:32:55 watusimoto    // Grab the script's environment table from the registry, place it on the stack
16:32:55 watusimoto    if(environmentIsGlobal)
16:32:55 watusimoto       lua_getglobal(L, environmentName);                    // -- function, table
16:32:55 watusimoto    else                                                     //      ** OR **
16:32:55 watusimoto       lua_getfield(L, LUA_REGISTRYINDEX, environmentName);  // -- function, table
16:32:56 watusimoto    lua_setfenv(L, -2);                                      // -- function
16:32:56 watusimoto }
16:32:57 watusimoto that's the methods
16:33:06 watusimoto it segfaults at the setfenv
16:33:23 watusimoto probably there is not enough stuff on the stack, or it's the wrong kind of stuff
16:33:43 watusimoto if you insert a LuaObject::dumpStack(L) just before the setfenv, you can see what is on the stack
16:33:54 watusimoto the comments tell you what to expect
16:34:01 watusimoto in this case, we expect a function and a table
16:34:29 watusimoto the function is the code we are about to execute in whatever is calling this function
16:34:55 watusimoto and the table is our "robot environment" -- a special little universe in which the robot lives
16:35:35 watusimoto I'm guessing that the table is nil for some reason, so the stack would have a function and a nil
16:35:44 raptor Total in stack: 3   [listed bottom to top]
16:35:45 raptor string: 'scripts/sandbox.lua:3: bad argument #1 to 'pairs' (table expected, got nil)'
16:35:47 raptor function
16:35:48 raptor nil
16:35:50 raptor Segmentation fault
16:35:52 watusimoto ok
16:36:01 watusimoto the string is an error message left over from somewhere else
16:36:09 watusimoto so something got mucked up before here
16:36:26 watusimoto do you have a script called sandbox.lua?
16:37:07 watusimoto sandbox is supposed to create a copy of the global environment.
16:37:24 watusimoto and it failed for some reason
16:37:31 raptor nope
16:37:37 raptor i just  /addbot
16:37:45 raptor wait
16:37:47 watusimoto ok, that's the problem
16:37:51 raptor let me look...  is that a new one?
16:37:55 watusimoto new
16:37:57 watusimoto ish
16:38:08 watusimoto it should be in the same folder as lua_helper_scripts.lua
16:38:08 raptor ok
16:38:11 raptor i found it
16:38:12 raptor it's there
16:38:24 raptor lua_helper_functions
16:38:41 watusimoto can you paste the contents here?
16:38:45 watusimoto it's short
16:39:02 raptor function table.copy(t)
16:39:04 raptor   local u = { }
16:39:05 raptor   for k, v in pairs(t) do u[k] = v end
16:39:07 raptor   return setmetatable(u, getmetatable(t))
16:39:08 raptor end
16:39:10 raptor sandbox_env = table.copy(_G)
16:39:12 raptor ^^ that's sandbox.lua
16:39:30 watusimoto so it's that for line that broke
16:39:57 raptor that looks like just a copy
16:39:58 watusimoto ok
16:40:22 watusimoto so sandbox_env = table.copy(_G) should copy _G
16:40:27 watusimoto but it's not finding _G
16:40:31 raptor pairs(t)  is wrong?
16:40:35 watusimoto _G is the global variable table
16:40:36 watusimoto no
16:40:39 watusimoto it's right
16:40:56 watusimoto probably we did something to destroy _G, or otherwise make it unavailable
16:41:13 raptor is _G the standard global stack?
16:41:19 watusimoto global table
16:41:28 watusimoto the stack is only for interfacing with C/C++
16:41:32 raptor ah ok
16:41:42 watusimoto I think
16:41:58 watusimoto looking at the C++ clode, we are running sandbox.lua in a brand new L
16:42:03 watusimoto right after it is created
16:42:59 watusimoto wait a minute
16:43:32 watusimoto aha
16:43:42 watusimoto I must not have checked in my copy of sandbox
16:44:38 watusimoto change sandbox_env = table.copy(_G) to robot_env = table.copy(_G) and add levelgen_env = table.copy(_G) and see if that fixes it
16:44:57 raptor so 2 lines in place of one?
16:45:00 watusimoto we are creating two copies of _G, one for robots and one for levelgens
16:45:01 watusimoto yes
16:45:19 watusimoto though we don't really need to anymore, that's what the C++ is expecting
16:46:05 watusimoto void Robot::prepareEnvironment() looks for a table called robot_env
16:46:06 raptor after that change, no crash when loading a levelgen level (but levelgen is borken)
16:46:19 watusimoto as is expected
16:46:45 raptor s_bot added just fine to a normal level
16:46:51 watusimoto ok, good
16:46:52 raptor and has proceeded to kill me a number of times..
16:47:02 watusimoto so you can check in the sandbox script
16:47:05 raptor ok
16:47:10 watusimoto I'll probably get rid of it tonight
16:47:37 watusimoto because we really only need the table.copy, and maybe we don't even need that
16:47:57 raptor ok pushed
16:48:05 watusimoto the only reason we copy the globals table is to keep a rogue bot from destroying the scripting environment for other bots
16:48:20 watusimoto and I'm not too worried about malicious bots
16:49:21 raptor evil bots
16:49:33 watusimoto especially if we get rid of the ability of bots to write to disk
16:49:40 BFLogBot - Commit f4389bbde572 | Author: buckyballreaction | Log: Watusimoto says this fixes the segfaults with loading levelgens and robots
16:49:42 raptor what!?
16:49:46 raptor they have that ability?
16:49:51 watusimoto I think so
16:50:03 watusimoto right now, we run this:
16:50:04 watusimoto luaL_openlibs(L);
16:50:16 watusimoto this adds all the standard libs to the lua environment
16:50:41 watusimoto we might get rid of some of the capabilities in lua_helper_xxx.lua
16:50:53 watusimoto we did at one point, anyway
16:51:17 watusimoto but I am not worried about making an airtight sandbox
16:51:45 watusimoto if someone writes a bot that crashes bitfighter, as long as it doesn't take down the OS as well, it's probably ok
16:52:00 watusimoto at least until we allow remote execution of scripts
16:52:12 raptor haha
16:52:21 watusimoto but since the server operator must install all scripts, I don't think the danger is too high
16:52:36 watusimoto ok, I've got to go
16:52:43 raptor speaking of remote execution...  do you think it would be useful for the master server to shutdown dedicated servers?
16:52:50 raptor ok
16:52:51 watusimoto will do more lua cleanup tonight
16:52:52 raptor see you later
16:52:53 watusimoto why?
16:53:11 raptor there was a case where one server operator had 4 copies of the same server up
16:53:26 raptor he swore that he had only one instance of bitfighterd running, but we new better...
16:53:29 raptor *knew
16:53:37 watusimoto huh
16:53:48 raptor we had to convince him to double check his process list for all users
16:53:49 watusimoto no, I don't think we need that capability
16:53:52 raptor ok
16:54:04 raptor it was just a thought
16:54:10 watusimoto it sounds like an isolated case of a spazzy op that once he learned better problem fixed
16:54:17 raptor yes
16:54:18 watusimoto ok, well, see you later
16:54:20 raptor later
17:18:55 Watusimoto_ has joined
17:19:15 Watusimoto_ hi
17:19:19 raptor hello
17:26:31 Watusimoto_ do you agree we are not overly concerned with one bot intentionally trampling on another's code?
17:26:43 raptor uhh...
17:26:49 raptor i'm not really
17:27:36 Watusimoto_ maybe we could have a metagame of corewars going on with the bots
17:27:46 Watusimoto_ they battle on the field and in the memory
17:28:21 raptor a tron-like environment?
17:28:28 raptor so wait
17:28:48 Watusimoto_ do you know corewars?
17:29:06 raptor are you saying that there is a possibility one bot access code form another of the same bot?
17:29:10 raptor maybe...
17:29:15 raptor let me jog my memory..
17:29:31 Watusimoto_ two assmebler programs trying to overwrite the others' memory
17:29:51 raptor ha!
17:29:55 raptor no, i've never seen this before..
17:30:07 Watusimoto_ I used to be really into it
17:30:40 Watusimoto_ anyway
17:31:11 Watusimoto_ before, when each bot was in it's own L (Lua instance), there was no issue
17:31:18 Watusimoto_ now they all run in the same :
17:31:19 Watusimoto_ L
17:31:33 Watusimoto_ so there is the possibiliy of bots interfering with each other
17:31:39 raptor yes, with swapping tables right?
17:31:43 Watusimoto_ all bots share the same globals table
17:32:08 Watusimoto_ but create these "functional environments" that sort of simulate a local globals table
17:32:26 Watusimoto_ these environments (one per script) can be made pretty watertight
17:32:31 raptor so if i create a global in s_bot with name 'var', and another in orbitbot with the same name, what happens?
17:32:50 Watusimoto_ each bot's var gets wrtitten to the local environment.  no problem
17:32:55 Watusimoto_ no conflict
17:32:57 raptor ok
17:33:38 Watusimoto_ one way to do the bots is to make a complete copy of the _G table, and give it to each bot, then cut off all further access to that table
17:33:53 Watusimoto_ that, combined with blotting out "dangerous" functions, creates a reasonably good sandbox
17:34:20 Watusimoto_ but you need to copy the _G table for every bot, which takes time and consumes memory
17:34:28 raptor in what way could sharing _G  be bad?  it'd have to be done in the c++ code, right?
17:34:29 Watusimoto_ theoretically, all could share this _G table
17:34:37 raptor or
17:34:53 Watusimoto_ well, for example, the print function is stored in the _G table
17:34:53 raptor is _G modifiable by *any* script if you specify it?
17:35:03 Watusimoto_ you could overwrite _G["print"] = nil
17:35:07 Watusimoto_ no more print function
17:35:59 Watusimoto_ in the sandbox example, access to _G gets rerouted to the function's environment table; if they run that code, that bot has no more print function, but the other bots are happy
17:36:25 raptor ah ok
17:36:25 Watusimoto_ You can crate a "metatable" for each table
17:36:37 raptor is it a large table?
17:36:59 Watusimoto_ that metatable handles access to requests for values not in the bot's environment table
17:37:26 raptor safest is to copy _G
17:37:32 Watusimoto_ my first attempt, the one described on stackoverflow, was to give each bot its own environment table, but let them share _G as a metatable
17:37:45 raptor and is it really that much more overhead?
17:38:02 Watusimoto_ so if a bot requested an enum value, for example, it would first check its own table, not there, then go to the global table
17:38:08 Watusimoto_ (transparently to the bot)
17:38:18 Watusimoto_ I don't know how much overhead it really is
17:38:43 Watusimoto_ for running 1-2 bots, it's nothing
17:39:01 LordDVG has joined
17:39:49 Watusimoto_ hello?
17:39:54 raptor hi
17:40:01 Watusimoto_ with /addbots 100, there is a reasonable delay
17:40:09 Watusimoto_ no idea about the memory overhead
17:40:23 Watusimoto_ probably not too much
17:40:28 raptor reasonable delay that is comparative to not copying _G?
17:40:33 Watusimoto_ but I'm not doing the real sandbox
17:40:55 Watusimoto_ for example, one of the things that gets copied is the print function
17:41:02 Watusimoto_ I am copying a pointer to the print function
17:41:06 Watusimoto_ not the function itself
17:41:32 Watusimoto_ I don't know how much more overhead will come from doing a deep copy of _G
17:41:46 Watusimoto_ but I found this snippet
17:41:46 raptor let me run a test with current revision
17:41:50 Watusimoto_ ok
17:41:51 Watusimoto_ /local env = setmetatable({}, {__index=function(t,k) if k=='_G' then return nil else return _G[k] end})
17:41:55 raptor 100 bots was ~30MB RAM
17:42:00 raptor before
17:42:37 Watusimoto_ this would let _G be a metatable for reading, but if you tried to do _G["print"] = nil, it would fail
17:43:00 Watusimoto_ and if you did print = nil
17:43:14 Watusimoto_ that would create a local copy of print that was nil, and would not b0rk other bots
17:43:26 raptor should _G be allowed to be modified by bots?  i'd say no...
17:43:30 Watusimoto_ no
17:43:47 Watusimoto_ definitely not
17:44:03 raptor i don't know what you did since last test, but RAM for 100 bots is now 18.7M
17:44:06 Watusimoto_ the question is do we make it impossible, or just difficult to do by accident?
17:44:09 raptor even less
17:44:23 raptor i'd say impossible
17:45:19 raptor oh yeah - we added the control tick
17:45:21 Watusimoto_ well I'm kind of wavering on that
17:46:35 Watusimoto_ I like the idea of total isolation, but I am not sure about the cost
17:46:55 raptor how can i test the cost of non-total isolation with the current revision?
17:46:57 Watusimoto_ and I am having trouble finding a use case where it would really be helpful
17:46:59 raptor is it an easy change?
17:47:06 Watusimoto_ not sure
17:47:16 Watusimoto_ maybe we have total isolation
17:47:26 Watusimoto_ now that I think through it a little more
17:47:46 Watusimoto_ how could one bot b0rk another's print function?
17:48:06 Watusimoto_ not sure it could
17:48:29 Watusimoto_ but with the code I posted above, I'm not sure it could, either... just not sure
17:49:11 raptor yeah, actually, i'm thinking don't copy the global table
17:49:29 Watusimoto_ so what's the use case for airtight sandboxes?
17:49:53 raptor if we allow full lua script functionality
17:50:05 raptor not sure why we'd need that, though
17:50:20 Watusimoto_ I'm not talking about giving bots disk write access or anything -- that's a different issue
17:50:54 Watusimoto_ I'm thinking of bots screwing up the scripting environment and causing bitfighter to need to be restarted to fix it
17:51:16 raptor maybe bitfighter should be more robust on the c++ side
17:51:42 raptor brb
17:58:06 raptor back
18:01:34 raptor or maybe a level change could 'reset' the scripting environment?
18:02:25 Watusimoto_ that would work
18:02:47 Watusimoto_ though not really necessary
18:11:37 raptor found an interesting site: http://opengameart.org
18:11:48 raptor there's sound effects and music there, too
18:14:15 Watusimoto_ love it already... now let's have a look
18:30:18 Watusimoto_ dinner time
18:30:29 raptor lunch time!
18:35:49 Watusimoto_ Quit (Ping timeout: 276 seconds)
20:31:14 Watusimoto_ has joined
20:56:56 LordDVG Quit (Quit: Leaving)
21:25:09 BFLogBot - Commit 575a47c855f8 | Author: watusim...@bitfighter.org | Log: Much improved Lua setup process -- probably can't get too much faster than this
21:36:16 raptor ooo
21:36:18 raptor i will test
21:38:34 raptor heh
21:38:44 raptor cannot open scripts/levels/6357.levelgen
21:38:50 raptor dir in a dir
21:39:09 raptor ***ROBOT ERROR*** cannot open scripts/robots/s_bot.bot: No such file or directory -- Aborting
21:39:12 raptor dir in a dir
21:41:24 raptor probably luaObject.cpp:624?
21:44:28 raptor yep that was it
21:44:33 raptor i fix
21:50:13 BFLogBot - Commit b048dd9b56de | Author: buckyballreaction | Log: Fix loading scripts
21:50:24 Watusimoto_ BFLogBot: levelgens don't work
22:08:03 raptor ha!
22:08:13 raptor robots didn't work either...
22:37:55 sam686 has joined
22:38:02 ChanServ sets mode +v sam686
22:44:01 raptor ok, i'm out
22:44:08 raptor bye
22:44:26 raptor Quit ()
23:30:27 BFLogBot - Commit 2a6b0e6d4925 | Author: watusim...@bitfighter.org | Log: Comment
23:30:29 BFLogBot - Commit 46a51e90909c | Author: watusim...@bitfighter.org | Log: Remove sandbox.lua dependency
23:30:30 BFLogBot - Commit e32161aefdb8 | Author: watusim...@bitfighter.org | Log: Merge
23:33:42 Watusimoto_ Quit (Ping timeout: 250 seconds)

Index Search ←Prev date Next date→

These logs were automatically created by BFLogBot on irc.freenode.net.

00:32:52		BFLogBot - Commit 40b254a6084b \| Author: watusim...@bitfighter.org \| Log: Rename method printToOglConsole to printToConsole (could affect some lua scripts)
00:32:54		BFLogBot - Commit adcc92474cb1 \| Author: watusim...@bitfighter.org \| Log: More efficient script startup, other cleanup and reorg
00:32:55		BFLogBot - Commit 470be8015578 \| Author: watusim...@bitfighter.org \| Log: Merge
00:41:06		Watusimoto Quit (Ping timeout: 246 seconds)
03:00:36		Heyub Quit (Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/)
03:40:09		raptor has joined
03:42:03		raptor Quit (Client Quit)
04:21:57		raptor has joined
04:21:57		ChanServ sets mode +o raptor
04:22:02	raptor	good evening
04:49:41		raptor Quit (Quit: Page closed)
05:38:34		kodaws has joined
08:09:14		watusimoto has joined
08:09:15		ChanServ sets mode +o watusimoto
08:12:14		sam686 Quit (Ping timeout: 245 seconds)
09:51:47		Watusimoto_ has joined
10:45:46		Watusimoto_ Quit (Ping timeout: 252 seconds)
11:24:39		kodaws Quit (Ping timeout: 240 seconds)
12:53:06		Watusimoto_ has joined
14:29:12		Watusimoto_ Quit (Ping timeout: 246 seconds)
14:41:14		raptor has joined
14:41:14		ChanServ sets mode +o raptor
14:41:27	raptor	good day
14:50:15		raptor changes topic to 'Bitfighter 017a released!: http://bitfighter.org/downloads'
14:50:19		raptor has left
14:50:21		raptor has joined
14:50:21		ChanServ sets mode +o raptor
14:51:51	watusimoto	hi
14:51:58	raptor	hello
14:52:37	raptor	i haven't tested your latest changes yet..
15:01:12	watusimoto	that's ok.-- neither have I
15:01:16	watusimoto	ok, off to german class
15:01:18	raptor	ha
15:01:20	raptor	later
15:02:07	raptor	seg fault
15:02:24	raptor	probably need to copy over new scripts..
15:03:58	raptor	valid segfault: http://pastie.org/3768556
15:04:27		BFLogBot - Commit a9616c2d3f40 \| Author: buckyballreaction \| Log: Remove s_bot from exe folder (again) since it is in resources
15:41:14	raptor	second valid segfault: http://pastie.org/3768782
15:41:35	raptor	first is starting a level with a levelgen; second is with adding bot to a normal level
16:30:22	watusimoto	any invalid segfaults?
16:30:34	raptor	hehe
16:30:46	raptor	just got those two.. and i made sure to copy over the new resources
16:30:56	raptor	and clean compile
16:31:30	watusimoto	levelgens not yet working!
16:31:50	watusimoto	lets look at the second
16:32:22	raptor	both have to do with lua environment set, i think
16:32:47	watusimoto	yes
16:32:50	watusimoto	the second
16:32:54	watusimoto	void LuaScriptRunner::setEnvironment(const char *environmentName, bool environmentIsGlobal)
16:32:54	watusimoto	{
16:32:55	watusimoto	// Grab the script's environment table from the registry, place it on the stack
16:32:55	watusimoto	if(environmentIsGlobal)
16:32:55	watusimoto	lua_getglobal(L, environmentName); // -- function, table
16:32:55	watusimoto	else // OR
16:32:55	watusimoto	lua_getfield(L, LUA_REGISTRYINDEX, environmentName); // -- function, table
16:32:56	watusimoto	lua_setfenv(L, -2); // -- function
16:32:56	watusimoto	}
16:32:57	watusimoto	that's the methods
16:33:06	watusimoto	it segfaults at the setfenv
16:33:23	watusimoto	probably there is not enough stuff on the stack, or it's the wrong kind of stuff
16:33:43	watusimoto	if you insert a LuaObject::dumpStack(L) just before the setfenv, you can see what is on the stack
16:33:54	watusimoto	the comments tell you what to expect
16:34:01	watusimoto	in this case, we expect a function and a table
16:34:29	watusimoto	the function is the code we are about to execute in whatever is calling this function
16:34:55	watusimoto	and the table is our "robot environment" -- a special little universe in which the robot lives
16:35:35	watusimoto	I'm guessing that the table is nil for some reason, so the stack would have a function and a nil
16:35:44	raptor	Total in stack: 3 [listed bottom to top]
16:35:45	raptor	string: 'scripts/sandbox.lua:3: bad argument #1 to 'pairs' (table expected, got nil)'
16:35:47	raptor	function
16:35:48	raptor	nil
16:35:50	raptor	Segmentation fault
16:35:52	watusimoto	ok
16:36:01	watusimoto	the string is an error message left over from somewhere else
16:36:09	watusimoto	so something got mucked up before here
16:36:26	watusimoto	do you have a script called sandbox.lua?
16:37:07	watusimoto	sandbox is supposed to create a copy of the global environment.
16:37:24	watusimoto	and it failed for some reason
16:37:31	raptor	nope
16:37:37	raptor	i just /addbot
16:37:45	raptor	wait
16:37:47	watusimoto	ok, that's the problem
16:37:51	raptor	let me look... is that a new one?
16:37:55	watusimoto	new
16:37:57	watusimoto	ish
16:38:08	watusimoto	it should be in the same folder as lua_helper_scripts.lua
16:38:08	raptor	ok
16:38:11	raptor	i found it
16:38:12	raptor	it's there
16:38:24	raptor	lua_helper_functions
16:38:41	watusimoto	can you paste the contents here?
16:38:45	watusimoto	it's short
16:39:02	raptor	function table.copy(t)
16:39:04	raptor	local u = { }
16:39:05	raptor	for k, v in pairs(t) do u[k] = v end
16:39:07	raptor	return setmetatable(u, getmetatable(t))
16:39:08	raptor	end
16:39:10	raptor	sandbox_env = table.copy(_G)
16:39:12	raptor	^^ that's sandbox.lua
16:39:30	watusimoto	so it's that for line that broke
16:39:57	raptor	that looks like just a copy
16:39:58	watusimoto	ok
16:40:22	watusimoto	so sandbox_env = table.copy(_G) should copy _G
16:40:27	watusimoto	but it's not finding _G
16:40:31	raptor	pairs(t) is wrong?
16:40:35	watusimoto	_G is the global variable table
16:40:36	watusimoto	no
16:40:39	watusimoto	it's right
16:40:56	watusimoto	probably we did something to destroy _G, or otherwise make it unavailable
16:41:13	raptor	is _G the standard global stack?
16:41:19	watusimoto	global table
16:41:28	watusimoto	the stack is only for interfacing with C/C++
16:41:32	raptor	ah ok
16:41:42	watusimoto	I think
16:41:58	watusimoto	looking at the C++ clode, we are running sandbox.lua in a brand new L
16:42:03	watusimoto	right after it is created
16:42:59	watusimoto	wait a minute
16:43:32	watusimoto	aha
16:43:42	watusimoto	I must not have checked in my copy of sandbox
16:44:38	watusimoto	change sandbox_env = table.copy(_G) to robot_env = table.copy(_G) and add levelgen_env = table.copy(_G) and see if that fixes it
16:44:57	raptor	so 2 lines in place of one?
16:45:00	watusimoto	we are creating two copies of _G, one for robots and one for levelgens
16:45:01	watusimoto	yes
16:45:19	watusimoto	though we don't really need to anymore, that's what the C++ is expecting
16:46:05	watusimoto	void Robot::prepareEnvironment() looks for a table called robot_env
16:46:06	raptor	after that change, no crash when loading a levelgen level (but levelgen is borken)
16:46:19	watusimoto	as is expected
16:46:45	raptor	s_bot added just fine to a normal level
16:46:51	watusimoto	ok, good
16:46:52	raptor	and has proceeded to kill me a number of times..
16:47:02	watusimoto	so you can check in the sandbox script
16:47:05	raptor	ok
16:47:10	watusimoto	I'll probably get rid of it tonight
16:47:37	watusimoto	because we really only need the table.copy, and maybe we don't even need that
16:47:57	raptor	ok pushed
16:48:05	watusimoto	the only reason we copy the globals table is to keep a rogue bot from destroying the scripting environment for other bots
16:48:20	watusimoto	and I'm not too worried about malicious bots
16:49:21	raptor	evil bots
16:49:33	watusimoto	especially if we get rid of the ability of bots to write to disk
16:49:40		BFLogBot - Commit f4389bbde572 \| Author: buckyballreaction \| Log: Watusimoto says this fixes the segfaults with loading levelgens and robots
16:49:42	raptor	what!?
16:49:46	raptor	they have that ability?
16:49:51	watusimoto	I think so
16:50:03	watusimoto	right now, we run this:
16:50:04	watusimoto	luaL_openlibs(L);
16:50:16	watusimoto	this adds all the standard libs to the lua environment
16:50:41	watusimoto	we might get rid of some of the capabilities in lua_helper_xxx.lua
16:50:53	watusimoto	we did at one point, anyway
16:51:17	watusimoto	but I am not worried about making an airtight sandbox
16:51:45	watusimoto	if someone writes a bot that crashes bitfighter, as long as it doesn't take down the OS as well, it's probably ok
16:52:00	watusimoto	at least until we allow remote execution of scripts
16:52:12	raptor	haha
16:52:21	watusimoto	but since the server operator must install all scripts, I don't think the danger is too high
16:52:36	watusimoto	ok, I've got to go
16:52:43	raptor	speaking of remote execution... do you think it would be useful for the master server to shutdown dedicated servers?
16:52:50	raptor	ok
16:52:51	watusimoto	will do more lua cleanup tonight
16:52:52	raptor	see you later
16:52:53	watusimoto	why?
16:53:11	raptor	there was a case where one server operator had 4 copies of the same server up
16:53:26	raptor	he swore that he had only one instance of bitfighterd running, but we new better...
16:53:29	raptor	*knew
16:53:37	watusimoto	huh
16:53:48	raptor	we had to convince him to double check his process list for all users
16:53:49	watusimoto	no, I don't think we need that capability
16:53:52	raptor	ok
16:54:04	raptor	it was just a thought
16:54:10	watusimoto	it sounds like an isolated case of a spazzy op that once he learned better problem fixed
16:54:17	raptor	yes
16:54:18	watusimoto	ok, well, see you later
16:54:20	raptor	later
17:18:55		Watusimoto_ has joined
17:19:15	Watusimoto_	hi
17:19:19	raptor	hello
17:26:31	Watusimoto_	do you agree we are not overly concerned with one bot intentionally trampling on another's code?
17:26:43	raptor	uhh...
17:26:49	raptor	i'm not really
17:27:36	Watusimoto_	maybe we could have a metagame of corewars going on with the bots
17:27:46	Watusimoto_	they battle on the field and in the memory
17:28:21	raptor	a tron-like environment?
17:28:28	raptor	so wait
17:28:48	Watusimoto_	do you know corewars?
17:29:06	raptor	are you saying that there is a possibility one bot access code form another of the same bot?
17:29:10	raptor	maybe...
17:29:15	raptor	let me jog my memory..
17:29:31	Watusimoto_	two assmebler programs trying to overwrite the others' memory
17:29:51	raptor	ha!
17:29:55	raptor	no, i've never seen this before..
17:30:07	Watusimoto_	I used to be really into it
17:30:40	Watusimoto_	anyway
17:31:11	Watusimoto_	before, when each bot was in it's own L (Lua instance), there was no issue
17:31:18	Watusimoto_	now they all run in the same :
17:31:19	Watusimoto_	L
17:31:33	Watusimoto_	so there is the possibiliy of bots interfering with each other
17:31:39	raptor	yes, with swapping tables right?
17:31:43	Watusimoto_	all bots share the same globals table
17:32:08	Watusimoto_	but create these "functional environments" that sort of simulate a local globals table
17:32:26	Watusimoto_	these environments (one per script) can be made pretty watertight
17:32:31	raptor	so if i create a global in s_bot with name 'var', and another in orbitbot with the same name, what happens?
17:32:50	Watusimoto_	each bot's var gets wrtitten to the local environment. no problem
17:32:55	Watusimoto_	no conflict
17:32:57	raptor	ok
17:33:38	Watusimoto_	one way to do the bots is to make a complete copy of the _G table, and give it to each bot, then cut off all further access to that table
17:33:53	Watusimoto_	that, combined with blotting out "dangerous" functions, creates a reasonably good sandbox
17:34:20	Watusimoto_	but you need to copy the _G table for every bot, which takes time and consumes memory
17:34:28	raptor	in what way could sharing _G be bad? it'd have to be done in the c++ code, right?
17:34:29	Watusimoto_	theoretically, all could share this _G table
17:34:37	raptor	or
17:34:53	Watusimoto_	well, for example, the print function is stored in the _G table
17:34:53	raptor	is _G modifiable by any script if you specify it?
17:35:03	Watusimoto_	you could overwrite _G["print"] = nil
17:35:07	Watusimoto_	no more print function
17:35:59	Watusimoto_	in the sandbox example, access to _G gets rerouted to the function's environment table; if they run that code, that bot has no more print function, but the other bots are happy
17:36:25	raptor	ah ok
17:36:25	Watusimoto_	You can crate a "metatable" for each table
17:36:37	raptor	is it a large table?
17:36:59	Watusimoto_	that metatable handles access to requests for values not in the bot's environment table
17:37:26	raptor	safest is to copy _G
17:37:32	Watusimoto_	my first attempt, the one described on stackoverflow, was to give each bot its own environment table, but let them share _G as a metatable
17:37:45	raptor	and is it really that much more overhead?
17:38:02	Watusimoto_	so if a bot requested an enum value, for example, it would first check its own table, not there, then go to the global table
17:38:08	Watusimoto_	(transparently to the bot)
17:38:18	Watusimoto_	I don't know how much overhead it really is
17:38:43	Watusimoto_	for running 1-2 bots, it's nothing
17:39:01		LordDVG has joined
17:39:49	Watusimoto_	hello?
17:39:54	raptor	hi
17:40:01	Watusimoto_	with /addbots 100, there is a reasonable delay
17:40:09	Watusimoto_	no idea about the memory overhead
17:40:23	Watusimoto_	probably not too much
17:40:28	raptor	reasonable delay that is comparative to not copying _G?
17:40:33	Watusimoto_	but I'm not doing the real sandbox
17:40:55	Watusimoto_	for example, one of the things that gets copied is the print function
17:41:02	Watusimoto_	I am copying a pointer to the print function
17:41:06	Watusimoto_	not the function itself
17:41:32	Watusimoto_	I don't know how much more overhead will come from doing a deep copy of _G
17:41:46	Watusimoto_	but I found this snippet
17:41:46	raptor	let me run a test with current revision
17:41:50	Watusimoto_	ok
17:41:51	Watusimoto_	/local env = setmetatable({}, {__index=function(t,k) if k=='_G' then return nil else return _G[k] end})
17:41:55	raptor	100 bots was ~30MB RAM
17:42:00	raptor	before
17:42:37	Watusimoto_	this would let _G be a metatable for reading, but if you tried to do _G["print"] = nil, it would fail
17:43:00	Watusimoto_	and if you did print = nil
17:43:14	Watusimoto_	that would create a local copy of print that was nil, and would not b0rk other bots
17:43:26	raptor	should _G be allowed to be modified by bots? i'd say no...
17:43:30	Watusimoto_	no
17:43:47	Watusimoto_	definitely not
17:44:03	raptor	i don't know what you did since last test, but RAM for 100 bots is now 18.7M
17:44:06	Watusimoto_	the question is do we make it impossible, or just difficult to do by accident?
17:44:09	raptor	even less
17:44:23	raptor	i'd say impossible
17:45:19	raptor	oh yeah - we added the control tick
17:45:21	Watusimoto_	well I'm kind of wavering on that
17:46:35	Watusimoto_	I like the idea of total isolation, but I am not sure about the cost
17:46:55	raptor	how can i test the cost of non-total isolation with the current revision?
17:46:57	Watusimoto_	and I am having trouble finding a use case where it would really be helpful
17:46:59	raptor	is it an easy change?
17:47:06	Watusimoto_	not sure
17:47:16	Watusimoto_	maybe we have total isolation
17:47:26	Watusimoto_	now that I think through it a little more
17:47:46	Watusimoto_	how could one bot b0rk another's print function?
17:48:06	Watusimoto_	not sure it could
17:48:29	Watusimoto_	but with the code I posted above, I'm not sure it could, either... just not sure
17:49:11	raptor	yeah, actually, i'm thinking don't copy the global table
17:49:29	Watusimoto_	so what's the use case for airtight sandboxes?
17:49:53	raptor	if we allow full lua script functionality
17:50:05	raptor	not sure why we'd need that, though
17:50:20	Watusimoto_	I'm not talking about giving bots disk write access or anything -- that's a different issue
17:50:54	Watusimoto_	I'm thinking of bots screwing up the scripting environment and causing bitfighter to need to be restarted to fix it
17:51:16	raptor	maybe bitfighter should be more robust on the c++ side
17:51:42	raptor	brb
17:58:06	raptor	back
18:01:34	raptor	or maybe a level change could 'reset' the scripting environment?
18:02:25	Watusimoto_	that would work
18:02:47	Watusimoto_	though not really necessary
18:11:37	raptor	found an interesting site: http://opengameart.org
18:11:48	raptor	there's sound effects and music there, too
18:14:15	Watusimoto_	love it already... now let's have a look
18:30:18	Watusimoto_	dinner time
18:30:29	raptor	lunch time!
18:35:49		Watusimoto_ Quit (Ping timeout: 276 seconds)
20:31:14		Watusimoto_ has joined
20:56:56		LordDVG Quit (Quit: Leaving)
21:25:09		BFLogBot - Commit 575a47c855f8 \| Author: watusim...@bitfighter.org \| Log: Much improved Lua setup process -- probably can't get too much faster than this
21:36:16	raptor	ooo
21:36:18	raptor	i will test
21:38:34	raptor	heh
21:38:44	raptor	cannot open scripts/levels/6357.levelgen
21:38:50	raptor	dir in a dir
21:39:09	raptor	*ROBOT ERROR* cannot open scripts/robots/s_bot.bot: No such file or directory -- Aborting
21:39:12	raptor	dir in a dir
21:41:24	raptor	probably luaObject.cpp:624?
21:44:28	raptor	yep that was it
21:44:33	raptor	i fix
21:50:13		BFLogBot - Commit b048dd9b56de \| Author: buckyballreaction \| Log: Fix loading scripts
21:50:24	Watusimoto_	BFLogBot: levelgens don't work
22:08:03	raptor	ha!
22:08:13	raptor	robots didn't work either...
22:37:55		sam686 has joined
22:38:02		ChanServ sets mode +v sam686
22:44:01	raptor	ok, i'm out
22:44:08	raptor	bye
22:44:26		raptor Quit ()
23:30:27		BFLogBot - Commit 2a6b0e6d4925 \| Author: watusim...@bitfighter.org \| Log: Comment
23:30:29		BFLogBot - Commit 46a51e90909c \| Author: watusim...@bitfighter.org \| Log: Remove sandbox.lua dependency
23:30:30		BFLogBot - Commit e32161aefdb8 \| Author: watusim...@bitfighter.org \| Log: Merge
23:33:42		Watusimoto_ Quit (Ping timeout: 250 seconds)