Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Koneki » Breakpoint not hit after attaching to Java application
Breakpoint not hit after attaching to Java application [message #1417031] Tue, 10 December 2013 16:33 Go to next message
Patrick Hoey is currently offline Patrick HoeyFriend
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.
Re: Breakpoint not hit after attaching to Java application [message #1417032 is a reply to message #1417031] Wed, 11 December 2013 11:40 Go to previous messageGo to next message
Simon Bernard is currently offline Simon BernardFriend
Messages: 339
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 https://wiki.eclipse.org/Koneki/LDT/Developer_Area/User_Guides/User_Guide_1.0#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 https://wiki.eclipse.org/Koneki/LDT/Developer_Area/User_Guides/User_Guide_1.0#Attach_session 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 #1417034 is a reply to message #1417032] Wed, 11 December 2013 16:47 Go to previous message
Patrick Hoey is currently offline Patrick HoeyFriend
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 in on the roadmap for LDT.

Anyways, thank you again.
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: Sun Nov 18 04:46:20 GMT 2018

Powered by FUDForum. Page generated in 0.02418 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top