Here is my problem. I am trying to debug a Lua script from Eclipse with the Koneki project plugin, and I have set a breakpoint within a Lua function. The breakpoint never gets hit, and it appears that the Lua attach debug process terminates. I even set the debug option to "Break at the first line" and this does work, but then as soon as I continue, the debug process terminates.

In my mind, I would think that I would start the DBGp Server (Lua Attach to Application), and then start my java app (which loads and calls functions of the Lua scripts via LuaJ). I then run the "Lua Application" with my lua script in order for the lua client to load.

I guess I am not clear on how to properly debug a Lua script within Eclipse (using Koneki Lua plugin) when the scripts are loaded from LuaJ within a Java application.

We will need more information to help you:
Which debugger transport layer do you use with LuaJ ?
Can you check the option "Enable DBGP logging" in the Lua attach launch configuration and post the logs here ?

I guess the primary issue that I am struggling with is the setup in order to debug a Lua script that is invoked in Java code via LuaJ (on Windows 7 platform). I have setup the Lua project, debugger server, and client connection. This setup seems more appropriate for lua scripts running independently though. My question is whether it is possible to set a breakpoint within a function of a lua script, and have this point break when invoked from Java via LuaJ.

1) For the debugger setup, I am launching the DBGP server, and connecting to it with the client file provided by the "Lua Debugger Client" link. I am using the LuaRocks 2.1 socket binaries as well as the LuaRocks runtime interpreter (5.1).
2) Here are the logs with "Enable DBGP logging" enabled:Quote:

It seems you are misleading something (I don't kown what), let's try explain the debugger from another point of view.
There are 2 ways to debug your lua code:

- Using the "Lua Attach to Application", you are responsible to call the debugger in your Lua code and to launch your Java application by yourself. This is explained in the user guide [1]. Starting the launch configuration will only start the DBGP server who is waiting for the debbugger to connect.

- Using the "Lua Application" launch configuration, you have to register your Java application as a Lua interpreter, see [2]. Then configure a launch configuration to use your interpreter. Launching the launch configuration will start your java application. If your Java application don't handle the -e option to execute some Lua code you have also to call the debugger in your code.

If your java application create more than one Lua thread you will have to restart the DBGP server and client for each Lua thread.

I hope this can help you, otherwise please try to precise your questions.

Ok, now I understand where my confusion was. I am new to the Lua environment, and it was made more confusing by using a third party integration tool (LuaJ) to interact with the Lua scripts. I now understand that there are two distinct methods to debug in Eclipse (LDT) with Lua. What I did not understand before is that LuaJ library itself is the interpreter, just like if Lua was installed with an executable.

Once I connected the dots, I understood how to make my debug target. For this example, I am using the "Lua Application" target for debugging.

The first step was adding my own interpreter. Under "Lua Application", I "managed interpreters" (generic Lua) in order to add LuaJ. It appears that the "Interpreter executable" field expects a specific file, so passing in the LuaJ command was not an option. I created a batch file (on Windows) and wrapped the LuaJ command in the file with the following line:

I also made sure my "Working Directory" was set to where my lua scripts were (through the Arguments tab)

My first problem was the following:
F:\Users\phoey\phoey_phoeyPC\workspace\cyberpunkgame-android\assets\data\scripts>java.exe -cp F:\Users\phoey\phoey_phoeyPC\workspace\cyberpunkgame\libs\luaj-jse-3.0-beta1.jar lua -e "require ('debugger')();" F:\Users\phoey\phoey_phoeyPC\workspace\cyberpunkgame-android\assets\data\scripts\atm.lua
org.luaj.vm2.LuaError: @debugger.lua:2283 Luaj-jse 3.0-beta1is not supported.
stack traceback:
debugger.lua:2265: in main chunk
string:1: in main chunk
[Java]: in ?
at org.luaj.vm2.lib.BaseLib$error.call(Unknown Source)
at org.luaj.vm2.lib.TwoArgFunction.call(Unknown Source)
at org.luaj.vm2.LuaClosure.execute(Unknown Source)
at org.luaj.vm2.LuaClosure.call(Unknown Source)
at org.luaj.vm2.lib.PackageLib$require.call(Unknown Source)
at org.luaj.vm2.LuaClosure.execute(Unknown Source)
at org.luaj.vm2.LuaClosure.onInvoke(Unknown Source)
at org.luaj.vm2.LuaClosure.invoke(Unknown Source)
at lua.processScript(Unknown Source)
at lua.main(Unknown Source)

The LuaJ interpreter returns "Luaj-jse 3.0-beta1" (supports Lua 5.2) but the client debugger.lua script expects either a "Lua 5.1" or "Lua 5.2". I modified the script for LuaJ support by setting the version to "Lua 5.2".

But now, after resolving that issue, I keep getting the following error:

The environment variables are set as well as the working directory. In putting print statements in, I have found that the M.init() is being called (in debugger.lua) where both executionplatform and workingdirectory parameters are nil.

The function tries to guess if the OS is windows with the following call:
local p = io.popen("echo %os%")

but the value returned is nil, and so the OS is set to Unix as the default and therefore never enters the windows path parsing code.

Any ideas on how to troubleshoot this issue? I don't understand why the io call (to open the process and run the echo command) is failing.

UPDATE: I added an assert around the io.popen call to get additional information. This is what I get:

UPDATE 2
I changed the line in iswindows() from
local p = io.popen("echo %os%")
to
local p = io.popen("cmd /C echo %os%")
and now it recognizes my system as Windows_NT (I am developing on a Windows 7 64bit system)

I also changed the line in getworkingdirectory() from
local p = io.popen("echo %cd%")
to
local p = io.popen("cmd /C echo %cd%")

For LuaJ to work, it appears I would have to implement my own transport interface ( based on Java sockets ) in order to use the DBGp Lua client. Depending on alternatives, I may or may not implement this.

In the last few days, I ported my Java source from using LuaJ to JNLua, including the Lua scripts. This actually gave me more control over the Lua calls made in Java, and so I am closer to the Lua layer. Now the LUA_PATH and LUA_CPATH environment variables are respected, and I can easily load third party native libraries in Lua using the JNLua interface.

In summary, there appear to be problems with debugging with LDT where the files are loaded from lua_load() (the dynamic code comment). There was one little excerpt in this forum that caught my attention in how the developer solved his problem:
"To use an embedded script you need to load it in the style of luaL_loadfile, pushing the filename onto the stack first with lua_pushfstring(L, "@%s", filename); and removing it after calling luaL_loadbuffer."