Re: Debugging memory leaks

[Sean Conner <sean@...>]

It was thus said that the Great nobody once stated:
> On 16/05/2019 20.30, Sean Conner wrote:
> >It was thus said that the Great Sean Conner once stated:
> >>
> >>[1]	I wrote a tool last year (not released) that I can
> >>interactively check a Lua state (using a text-based UI).  I was
> >>able to integrate it into the event framework, so I was able to
> >>check various tables in real time (as the program was processing
> >>network events) to see what table was growing without bound.
> >>
> >>Attached is a screen shot for those that might be interested.
> >
> >I forgot the screen shot.  Sigh.
> >
> >-spc (Included this time ...)
> 
> That sounds cool!  Can you briefly describe how you get the information
> from the Lua state to the tool?  (Apart from invasive hooks everywhere &
> blasting stuff out via sockets, I'd have no idea how to do this…)

  No invasive hooks, and use of the standard debug module.

  It's interactive at the command line and I typically use it from the stock
Lua interpeter:

[spc]lucy:~>lua
Lua 5.3.5  Copyright (C) 1994-2018 Lua.org, PUC-Rio
> luaview = require "org.flummux.luaview"
> luaview.run()

  But because it's a module and *not* an application, you can embed it.  So
I added it to the code in question:

	-- This is UDP socket that accepts incoming requests.  It will
	-- then spawn a coroutine to handle sending the data to an HTTP
	-- endpoint

	nfl.SOCKETS:insert(usock,'r',function() -- [1]
	  local remote,packet,err = usock:recv()
	  nfl.spawn(handler,remote,packet)
	end)

	luaview = require "org.flummux.luaview"
	luaview.init() -- intialize the luaview module

	-- When a keyboard event is detected, run one step
	-- of the luaview module.  This give us a real-time
	-- interactive view into the current Lua state as the
	-- program is running.  I can check the global environment,
	-- the registry, upvalues, metatables, etc. 

	nfl.SOCKETS:insert(luaview,'r',function()
	  if not luaview.step() then
	    nfl.SOCKETS;remove(luaview)
	    luaview.close()
	  end
	end)

	nfl.server_eventloop()

  So it's not a remote, interactive viewer thing---it's purely a local,
interactive thing.

  The function luaview.step() just reads the next key from the keyboard and
handles that one key.  luaview.run() calls luaview.init(), luaview.step()
(in a loop) and luaview.close().  That's pretty much it to the luaview API.

  -spc (Never given it thought of making it remote ... )

[1]	My wrapper for select() [2] will attempt to call _tofd() via a
	metatable on the second parameter.  My other modules, like
	org.conman.net (and org.flummux.luaview) support this.  If you use
	org.conman.fsys, it will add a _tofd() function to the FILE*
	metatable in Lua so one can pass in items like io.stdin [3].

[2]	Which will use epoll() under Linux, poll() under other Unix systems,
	and only if poll() isn't available, select().  The API is the same
	across all three implementations.

[3]	I'm still unsure if monkey patching like this is a Good Thing or
	not.