Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Lua Development Tools » Breakpoint not hit after attaching to Java application
Breakpoint not hit after attaching to Java application [message #1220255] Tue, 10 December 2013 11:33 Go to next message
Patrick Hoey is currently offline Patrick Hoey
Messages: 7
Registered: December 2013
Junior Member
I have ported my java code/scripts to use JNLua instead of LuaJ. JNLua respects the LUA_PATH and LUA_CPATH variables so configuration works painlessly.

Background:
(Running on Windows 64bit platform)
1) I have downloaded/installed LDT v1.0.1 in Eclipse v4.2.0
2) I have downloaded/installed JNLua v1.0.3 with Lua v5.2.1 binaries
3) I have configured my LuaRocks environment to compile Luasocket v3.0rc1-1 linking with Lua v5.2.1 libs
4) Updated PATH, LUA_PATH, and LUA_CPATH to reflect these changes and added them to the environment variables in Eclipse/LDT
5) Created a "Lua Attach to Application" target
6) Placed the "Lua Debugger Client" in the LUA_PATH path
7) Added entry point [require ("debugger")("localhost", 10000, "luaidekey")] to my lua script for debugging

I have been able to debug a dummy Lua project, so I know the environment and binaries are setup correctly.

Current Workflow:
1) Start my "Lua Attach to Application" target
2) Start my Java application
3) I can see the process attach to the Lua debugging engine

Issue:
My breakpoints are never hit when I attach and the Lua functions are called

Here is how I am calling the Lua script from Java:
import com.naef.jnlua.LuaState;
...
    luaState.openLibs();
    luaState.load(
    	Gdx.files.internal(scriptFileName).read(), //read() returns InputStream
    	Gdx.files.internal(scriptFileName).file().getName(), //getName() returns filename, "atm.lua"
    	"bt"); //read as binary or text
    // Evaluate the chunk, thus defining the function 
    luaState.call(0, 0); // No arguments, no returns 
...

Then when called later:
...
		luaState.getGlobal("create");
		luaState.pushJavaObject(entity); // Push argument #1 
		luaState.call(1, 0); // 1 argument, 0 return 
...


I don't know if this is relevant, but in one of the posts this was used in the Lua script (in this case "atm.lua") for troubleshooting:
print(debug.getinfo(1).source)

For a value, I get:
atm.lua

Script Debug Log (after this run)
Event	TERMINATE from org.eclipse.koneki.ldt.debug.core.internal.attach.LuaAttachDebuggingEngineRunner$1
Event	CREATE from org.eclipse.koneki.ldt.debug.core.internal.attach.LuaAttachDebuggingEngineRunner$1
Event	CHANGE from org.eclipse.debug.core.model.RuntimeProcess
Event	CREATE from org.eclipse.debug.core.model.RuntimeProcess
Event	CHANGE from org.eclipse.debug.core.model.RuntimeProcess
Event	CREATE from org.eclipse.jdt.internal.debug.core.model.JDIThread
Event	CREATE from org.eclipse.jdt.internal.debug.core.model.JDIThread
Event	CREATE from org.eclipse.jdt.internal.debug.core.model.JDIThread
Event	CREATE from org.eclipse.jdt.internal.debug.core.model.JDIThread
Event	CREATE from org.eclipse.jdt.internal.debug.core.model.JDIThread
Event	CREATE from org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget
Event	RESUME from org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget
Event	CHANGE from org.eclipse.jdt.internal.debug.core.model.JDIThread
Event	TERMINATE from org.eclipse.jdt.internal.debug.core.model.JDIThread
Event	CREATE from org.eclipse.jdt.internal.debug.core.model.JDIThread
Event	CREATE from org.eclipse.jdt.internal.debug.core.model.JDIThread
Event	CREATE from org.eclipse.jdt.internal.debug.core.model.JDIThread
Event	CREATE from org.eclipse.jdt.internal.debug.core.model.JDIThread
Event	MODEL_SPECIFIC/5 from org.eclipse.dltk.dbgp.internal.DbgpDebugingEngine
<<	<?xml version="1.0" encoding="UTF-8" ?>
<init idekey="luaidekey" parent="" fileuri="unknown:/" language="Lua" xmlns="urn:debugger_protocol_v1" session="1386691895_thread: 0077E000" protocol_version="1.0" thread="thread: 0077E000" appid="Lua DBGp"/>
>>	feature_set -n max_children -i 285 -v 32
<<	<?xml version="1.0" encoding="UTF-8" ?>
<response xmlns="urn:debugger_protocol_v1" transaction_id="285" success="1" command="feature_set" feature="max_children"/>
>>	feature_set -n max_depth -i 286 -v 2
<<	<?xml version="1.0" encoding="UTF-8" ?>
<response xmlns="urn:debugger_protocol_v1" transaction_id="286" success="1" command="feature_set" feature="max_depth"/>
>>	feature_set -n max_data -i 287 -v 8192
<<	<?xml version="1.0" encoding="UTF-8" ?>
<response xmlns="urn:debugger_protocol_v1" transaction_id="287" success="1" command="feature_set" feature="max_data"/>
>>	feature_get -n stdin -i 288
<<	<?xml version="1.0" encoding="UTF-8" ?>
<response xmlns="urn:debugger_protocol_v1" supported="0" transaction_id="288" command="feature_get" feature_name="stdin"><![CDATA[false]]></response>
>>	feature_set -n notify_ok -i 289 -v 1
<<	<?xml version="1.0" encoding="UTF-8" ?>
<response xmlns="urn:debugger_protocol_v1" transaction_id="289" success="0" command="feature_set" feature="notify_ok"/>
>>	stdout -c 2 -i 290
<<	<?xml version="1.0" encoding="UTF-8" ?>
<response transaction_id="290" success="1" command="stdout" xmlns="urn:debugger_protocol_v1"/>
>>	stderr -c 2 -i 291
<<	<?xml version="1.0" encoding="UTF-8" ?>
<response transaction_id="291" success="1" command="stderr" xmlns="urn:debugger_protocol_v1"/>
>>	breakpoint_set -r 0 -t line -s enabled -n 15 -i 292 -f file:///F:/Users/phoey/phoey_phoeyPC/workspace/cyberpunkgame-android/assets/data/scripts/atm.lua
<<	<?xml version="1.0" encoding="UTF-8" ?>
<response state="enabled" xmlns="urn:debugger_protocol_v1" id="0" transaction_id="292" command="breakpoint_set"/>
>>	breakpoint_set -r 0 -t line -s enabled -n 34 -i 293 -f file:///F:/Users/phoey/phoey_phoeyPC/workspace/cyberpunkgame-android/assets/data/scripts/atm.lua
<<	<?xml version="1.0" encoding="UTF-8" ?>
<response state="enabled" xmlns="urn:debugger_protocol_v1" id="1" transaction_id="293" command="breakpoint_set"/>
>>	breakpoint_set -r 0 -t line -s enabled -n 24 -i 294 -f file:///F:/Users/phoey/phoey_phoeyPC/workspace/cyberpunkgame-android/assets/data/scripts/atm.lua
<<	<?xml version="1.0" encoding="UTF-8" ?>
<response state="enabled" xmlns="urn:debugger_protocol_v1" id="2" transaction_id="294" command="breakpoint_set"/>
>>	breakpoint_set -r 0 -t line -s enabled -n 12 -i 295 -f file:///F:/Users/phoey/phoey_phoeyPC/workspace/cyberpunkgame-android/assets/data/scripts/atm.lua
<<	<?xml version="1.0" encoding="UTF-8" ?>
<response state="enabled" xmlns="urn:debugger_protocol_v1" id="3" transaction_id="295" command="breakpoint_set"/>
>>	run -i 296
Event	CREATE from org.eclipse.dltk.internal.debug.core.model.ScriptThread
Event	MODEL_SPECIFIC/4 from org.eclipse.dltk.internal.debug.core.model.ScriptThread
Event	RESUME from org.eclipse.dltk.internal.debug.core.model.ScriptThread
Event	CHANGE from org.eclipse.dltk.internal.debug.core.model.ScriptThread
Event	MODEL_SPECIFIC/2 from org.eclipse.koneki.ldt.debug.core.internal.attach.LuaAttachDebuggingEngineRunner$1
<<	<?xml version="1.0" encoding="UTF-8" ?>
<stream xmlns="urn:debugger_protocol_v1" type="stdout"><![CDATA[IyMjIyMjIyMjIyMjIyMjI0RFQlVHR0VSIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMNCg==
]]></stream>
<<	<?xml version="1.0" encoding="UTF-8" ?>
<stream xmlns="urn:debugger_protocol_v1" type="stdout"><![CDATA[YXRtLmx1YQ0K
]]></stream>
<<	<?xml version="1.0" encoding="UTF-8" ?>
<stream xmlns="urn:debugger_protocol_v1" type="stdout"><![CDATA[IyMjIyMjIyMjIyMjIyMjI0RFQlVHR0VSIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMNCg==
]]></stream>


Question(s)
1) Am I doing anything obviously wrong as the reason for why I am not hitting the breakpoints when the function is called?
2) What are areas that I can troubleshoot for these types of issues?

Thanks.

UPDATE:
In scouring the forums, and looking at the debugger.lua client file, it seems that any chunk loaded using lua_load() is considered dynamic code and is not supported. The line in debugger.lua states: "Dynamic code (compiled with load or loadstring) is not handled (the debugger will step over it, like C code)." The JNLua call that I use to load the chunk from the file calls lua_load(). If this is the case, and the code is actually compiled to byte code on the stack on load, this would be the reason the debugger can't hit the breakpoint.

Does this seem a reasonable reason why I am having this problem?

[Updated on: Tue, 10 December 2013 18:03]

Report message to a moderator

Re: Breakpoint not hit after attaching to Java application [message #1220373 is a reply to message #1220255] Wed, 11 December 2013 06:40 Go to previous messageGo to next message
Simon Bernard is currently offline Simon Bernard
Messages: 164
Registered: July 2009
Senior Member
Hi Patrick,
You're right, currently the debugger is not able to manage "dynamic code". (but not sure it's your case)

By default, to identify lua file, debugger client and server use the absolute path of the file.
(This could change if you not use the default source mapping : local resolution => see launch configuration Lua Attach to Application)

To retrieve the absolute path of a lua file, the "Lua Debugger Client", use debug.getinfo(1).source.
If it is a absolute path, there nothing to do.
If this is a relative path, we try to retreive the absolute path by concatenate working directory + relative path from debug.getinfo(1).source

A regular problem could be that working directory is not guess correctly so you could set it by using the DBGP_WORKINGDIR environment variable or passing it as parameters

Maybe the problem could be also solved by using absolute path when you load the file :
luaState.load(
    	Gdx.files.internal(scriptFileName).read(), 
    	Gdx.files.internal(scriptFileName).file().getAbsolutePath(), => you could path the absolute path here maybe this will works. (not sure getAbsolutePath is exactly the good method :p)
    	"bt"); //read as binary or text
Re: Breakpoint not hit after attaching to Java application [message #1220424 is a reply to message #1220373] Wed, 11 December 2013 11:47 Go to previous message
Patrick Hoey is currently offline Patrick Hoey
Messages: 7
Registered: December 2013
Junior Member
Hello Simon,

Thank you for the reply and recommendations.

As for my environment, I am using the default source mapping, local resolution.

I set the DBGP_WORKINGDIR to my Lua script project directory, and just for testing, I passed in the entire absolute path. The breakpoint was still not hit.

I also (just for testing) passed in the name of the file as the absolute path in the LuaState.load() call in my Java code. "debug.getinfo(1).source" returned the full absolute path to the script file as expected, but the breakpoint still was not hit.

I troubleshooted a little further and put print statements in the debugger.lua file on all the variables used to initialize the debugger. All the values printed out correct, including "workingdirectory."

Unfortunately, with the working directory set correct, the debugger *should* have the information necessary in order to evaluate the path where the atm.lua script is.

Out of desperation at this point, I looked at alternative debug environments and found ZeroBrane's Studio Lua Debugger. I installed and set a breakpoint, and without much configuration was able to debug my script. I don't know if this has to do with dynamic code, but if it does, I hope dynamic code support is on the roadmap for LDT.

Anyways, thank you again.

[Updated on: Wed, 11 December 2013 13:36]

Report message to a moderator

Previous Topic:Sample code used in LDT to generate AST
Next Topic:Proper method to debug Lua script from Luaj project
Goto Forum:
  


Current Time: Mon Sep 01 09:51:41 EDT 2014

Powered by FUDForum. Page generated in 0.01640 seconds