Re: error() or nil, 'error msg'

[Sean Conner <sean@...>]

It was thus said that the Great Sean Conner once stated:
> It was thus said that the Great William Ahern once stated:
> > On Thu, Sep 11, 2014 at 09:50:29AM -0400, Sean Conner wrote:
> > > It was thus said that the Great Andrew Starks once stated:
> > <snip>
> > > > Are there interesting differences between how you think about / deal with
> > > > error handling in C/C++ vs. Lua?  Accepting that the mechanisms are
> > > > different, do you do more "try to recover" code in C?
> > > 
> > >   I don't program in C++, so I don't use exceptions.  In regard to error
> > > handling, I tend to handle errors in Lua like I do in C.  And I don't really
> > > do "recover" code in C.  [2][3]
> > > 
> > 
> > What do you mean by recover? Surely you handle errors like EMFILE and ENOMEM
> > without exiting the process.
> 
>   How would *you* handle ENOMEM?  

  Just for kicks, I decided to limit the amount of memory Lua has to see how
it handle things.  I then ran luarocks with this limited memory.  So
technically, what's running is "lua" (Lua 5.1 version), the sample Lua
interpreter that comes with Lua, which in turn, is running the code for
LuaRocks.  I am limiting the total virtual memory space the process can us
(setrlimit(RLIMIT_AS)).  I'm doing this on a 32-bit Linux system.

  So, with that out of the way ... 

  At 128k of memory, I get:

	core         false        	-- no core file produced
	pid          18441
	rc           9           	-- this is actually the signal the child received
	status       "terminated" 	-- informs me this was a signal kill
	description  "Killed"     	-- and it was the really nasy one

  1M resulted in the same error.  At 2M we get:

/usr/local/bin/lua: error while loading shared libraries: libncurses.so.5: failed to map segment from shared object: Cannot allocate memory

  but we didn't receive a signal this time:

	status       "normal"
	description  "failure 127"
	pid          18445
	rc           127

  It's only at 4M do we get Lua running:

	...

VARIABLES
        Variables from the "variables" table of the configuration file
        can be overriden with VAR=VALUE assignments.

COMMANDS
/usr/local/bin/lua: not enough memory

  and it's a normal, non-signal exit:

	status       "normal"
	description  "failure 1"
	pid          18450
	rc     	      1

  Looking at the code (lua.c), I see it calls lua_cpcall() and prints the
resulting error if there is one.  I then decided to modify luarocks to do a
pcall(), so I could catch the out of memory error myself and ... it's
interesting.  The patched luarocks:

	-- rest of the code is left untouched

	okay,err = pcall(command_line.run_command,...) 
	if not okay then
	 print("RED ALERT!  RED ALERT!")
	 print(err)
	 os.exit(1)
	end

And I run the patched version:

/usr/local/bin/lua: error loading module 'luarocks.command_line' from file '/usr/local/share/lua/5.1/luarocks/command_line.lua':
        not enough memory
stack traceback:
        [C]: ?
        [C]: in function 'require'
        ./luarocks:8: in main chunk
        [C]: ?


  So it didn't even get to run my handler.  Another run:

	...

VARIABLES
        Variables from the "variables" table of the configuration file
        can be overriden with VAR=VALUE assignments.

COMMANDS
RED ALERT!  RED ALERT!
not enough memory

and I was able to catch it.  Another run and it runs all the way through
without error.  Very interesting.  Pushing the memory limit down to 3M and
sometimes I get the "RED ALERT!" error, sometimes I can't even load a shared
library.

  To me, that says trying to handle out-of-memory conditions from within Lua
is dicey at best.  Interesting.

  -spc (Not that I've run into that issue with Lua since I don't restrict it
to such small amounts of memory ... )

  -spc (Since when is 4M "a small amount of memory?"  My first computer
	didn't even have 64K!)