Home » Archived » 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 16:33  |
 Patrick Hoey
Messages: 14
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 23: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 11:40  |
Simon Bernard
Messages: 345
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 16:47 |
Patrick Hoey
Messages: 14
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 18:36] Report message to a moderator |
|
|
Goto Forum:
Current Time: Fri Apr 19 06:30:50 GMT 2024
Powered by FUDForum. Page generated in 0.02198 seconds |
] 
Search
Help
Register
Login
Home
