I have a following setup:
LuaJIT 64bit in .NET managed, 64bit LuaSocket dll
ZeroBrane 1.80; MobDebug 0.705
Then I have several Lua scripts that are to be launched on specific events and I m trying to debug it.
First script - scripts/OnCreateInstance.lua also starts the MobDebug.
Debugging is working fine in this first script - debugger gets connected on require('mobdebug').start() and also following breakpoints work as expected, but breakpoints in other scripts are never hit.
I've went through the https://studio.zerobrane.com/doc-faq#why-breakpoints-are-not-triggered and haven't found anything suspicious.
debug.getinfo(1,"S").source returns scripts/onstartinstance.lua and scripts/onpushbutton.lua for the second script, which is correct. I am on Windows, so case sensitivity should not apply, and when I've switched the debugger verbose, I've still never seen any info about hitting the breakpoint.
I've also tried listing all the breakpoints in the second script, and all the breakpoints are listed, they just don't hit.
Do someone have any idea, what could be the problem? My only idea is, that it could be because of the second script is run from a different thread that the first script, but that is a thing I cannot avoid and have no idea how to work it around...
Thanks for any help
If the project directory is set correctly and the breakpoints are not triggered from other threads (not individual Lua states), then try adding require('mobdebug').on() calls to those threads/coroutines to enable breakpoints (as described in the first option in the documentation).
Related
Is it possible to attach two debugger to one process ?
Recently, I had developed a Metro Style App in HTML5/CSS and that was calling a Window Runtime Component written in C#. What I wanted to do was attach two debugger to same process. One at JavaScript & another at C# code.
The Step I followed:
I opened two visual studio instances targeting same solution.
I put a breakpoint in JavaScript code and f5/run the application via VS instance 1.
But, when I tried to attach 2nd debugger in C# window runtime component via VS instance 2 it gives me a dialog saying "Debugger already attached to process".
I've seen a Window Runtime presentation in which the speaker did the same successfully. Kindly, help me out with this.
That's not possible.
See here:
For both managed-only and native-only debugging, you can only attach 1
debugger to a process.
Why?
The native debugger steals debug events
from underneath the managed debugger. This confuses the
managed-debugger and will cause it to crash. The native debugger has
no way of coordinating with the managed-debugger here.
You don't need 2 debuggers to do that. You can use the same debugger to debug both. Just make sure your solution contains both projects and just put your breakpoints where you need them
Sometimes Visual Studio does not allow me to set breakpoints in MVC views. This has happened to me scores of times, but it doesn't happen for every view and I don't know why.
When you click on the left-hand bar to place a breakpoint, it places a white circle instead of the normal red circle. The message when you hover over it is "The breakpoint will not currently be hit. The source code is different from the original version." It goes on to describe how to allow breakpoints to be hit, but that produces strange results and I don't want that anyways.
If the error is correct, then I want to run the original source code. I don't know what's going on behind the scenes in VS; I try rebuilding and all that but it doesn't help. I'm running in Debug mode in VS 2012.
This could be caused by many things, but a few items to check which I've helped people with recently:
First step: there must be a PDB file alongside the DLL to enable debugging. (see: What is a PDB file?) Make sure you have the PDB in the executing directory.
Clean to remove all the old DLLs from your bin folders.
Ensure that your application is running a build of your current code (the same version you have in Visual Studio). Don't assume that it is just because you clicked 'build' or 'deploy'. If no changes were detected then things often don't happen. Check the build time of the assembly, or change something and rebuild to see the file size change.
If you're running something web-related, make sure a browser isn't caching code, or IIS isn't holding a long running process.
Kill any running Visual Studio Development Server instances (you can do this from task manager, or more simply from the system tray - they look like an IE logo and when you hover over them they'll tell you which port they run on).
Restart IIS using iisreset from a command prompt.
Check the settings for Debugging in Visual Studio (Tools > Options > Debugging > Symbols) You want to automatically load symbols, and if you're linking other assemblies you need to reference their PDB files here.
So I had this issue this morning and the fix for me was related to razor syntax.
I was setting a variable inside an if statement
#If (my condition)
{
myVar1 = "blah blah blah"
#myVar2 = 1 <== This line here was causing my razor to crap out on render
}
So all of the other things are good things however, improper razor syntax can also cause the breakpoint issue. In this case it was the # symbol on myVar2 inside the code block... Just an FYI
The simplest solution I've found to work around this problem is:
Set a breakpoint in the controller code that is right before the View is called. Then, when that breakpoint is hit, step through (using F10) several times. It will go through _ViewStart.cshtml and maybe another thing or two. But soon it will get to the view.
Once you are in the view, then hitting F5 (continue) will take you to the breakpoint in the view.
Fom the answer nothing worked for me to set a breakpoint in the javascript code.
I moved the javascript code inside to file Scripts\myscript.js and replaced the script block to
<script src="#Url.Content("~/Scripts/myscript.js")"></script>
To add to #kirk-broadhurst answer, (please amend if possible), double check your web.config, specifically the compilation flag under system.web. Even if you are building for debug, if the debug attribute is set to false, you will run into issues debugging Razor.
<system.web>
<compilation debug="true" targetFramework="4.6" />
</system.web>
Make sure that "debug" is set and Voila ... debug is working again:-)
Make sure your Solution configuration set to Debug not on release.
Thanks
My company has a program that uses Lua embedded in its runtime, loading up .lua files from disk and executing functions defined in them repeatedly.
Is there a way to attach to the running process and set breakpoints in my .lua files? (I'd accept either gdb-style command-line debugging as part of the Lua distribution, or perhaps a third-party IDE that provides Visual-Studio-like GUI breakpoints.)
Or is what I'm asking for entirely nonsensical and impossible given the nature of the runtime loading up random files from disk?
Edit: Looks like it's not nonsensical, given that Lua's own debug.getinfo() function can determine the source file for a given function, and debug.sethook() allows a callback for each new line of code entered. So, it's reasonable to load source code from disk and be able to tell when the interpreter is executing a particular line of code from that file. The question remains: how do I latch onto an existing process that has a Lua interpreter and inject my own trace function (which can then watch for file/line number pairs and pause execution)?
If you can modify the .lua files, you can insert the following call just before anything you need to debug:
require 'remdebug.engine'.start()
It starts the RemDebug Lua debugger engine and tries to connect to a controller. If it cannot connect, it will just continue running as normal. I did some fixes to the debugger engine, such as dealing with temporary variables, and my student is working on a debugger GUI (due next year).
In the meantime, you can try if Lua Development Tools works for you. It features a debugger similar to RemDebug, which should be possible to set up as follows:
require("debugger")(host, port, idekey)
Alternatively, you can use SciTE-debug, which is an extension to the SciTE editor, and can serve as a controller to RemDebug. Just make sure you insert the call to remdebug.engine.start somewhere in your Lua code and insert this into the SciTE output window:
:debug.target=remote.lua
When you start your program, SciTE should show the source and current line.
I've been using Decoda editor for that. It allows you to attach to a running C++ application, after that it detects that you're running a Lua Interpreter within your C++ code and show your Lua source code, where you can add beakpoints and inspect variables as usual.
This is an alternative I use after much searching. If you have an external executable that loads lua, I got this working in a few minutes. The op is very responsive, it has an interactive debugger which loads your code you can place debug points interactively. It doesn't have an editor, but I use scite or crimson editor and start the executable, one line in your main lua module enables the debugger.
http://www.cushy-code.com/grld/ - this link seems dead now
I've moved to eclipse.org/ldt it has an ide and integrated debugger, recommended
hth
The Lua plugin for IntelliJ has a working debugger with no special setup required other than pointing to your Lua interpreter.
Here's a screencast of it:
http://www.screencast.com/t/CBWIkoZPg
Similar to what Michal Kottman described, I have implemented a debugger based on RemDebug, but with additional fixes and features (on github: https://github.com/pkulchenko/MobDebug).
You can update your .lua file with require("mobdebug").start("localhost", 8171) at the point where you want the debugging to start. You can then use the command line debugger to execute commands, set breakpoints, evaluate/execute expressions and so on.
As an alternative, you can use ZeroBrane Studio IDE, which integrates with the debugger and gives you a front-end to load your code and execute same debugger commands in a nice GUI. If you want to see the IDE in action, I have a simple demo here: http://notebook.kulchenko.com/zerobrane/live-coding-in-lua-bret-victor-style.
You should probably use Decoda.
Go to Debug -> Processes -> Attach to attach your process. This should work fine.
Well the easiest way is this, thanks to the genius author
https://github.com/slembcke/debugger.lua
you don't need to setup a remote debug server ,just require one file,and simplely call dbg() and it will pause,just like gdb
an tutorial is also shipped with it, check it out.
After installation of Delphi 6 at new working station I issued problem with breakpoints. In debug mode environment doesn't trigger breakpoints like they are not placed at all...
Have you experienced similar situation? I suppose reason is some setting, but I cannot find which one...
TnX in advance!
Nemanja
Yes, this sometimes happens (not only in 6).
Enable all debug information except debug DCU's unless you want to debug the Borland code. (Don't forget to check for compiler switches in the code).
Disable code optimizer.
Rebuild all code.
If you are using DLL's be sure to enable debug code in all projects and set the host application to the right executable.
If that fails.
Be sure that there are blue dots at the code.
Be sure you have the right source file. You can check this by adding an error (for example dghasgsgd) and recompile, if the compiler accepts, this is not the right source file.
Be sure the code is reached (add a SendMessage statement or a message box so you can be sure the statement is reached.).
Restart the compiler. Or even restart the pc.
If that fails.
Take a break. Have a lunch or get something to drink.
Return and show the problem to a coworker. (preferably a programmer too).
I applied all settings that #Gamecat suggested, so you can look at this answer like short addition to previous answer.
I missed only one more to solve my problem. In Tools>Debugger Options I checked Integrated Debugging which alive my breakpoints. When breakpoints started to work, I got error message 'Project _.exe raised exception class EAccessViolation with message 'Access violation at address 4CDEB080 in module 'IDPDX32.DLL'. ' For solving this issue I just unchecked option 'Stop on Delphi Exceptions' in menu Tools>Debugger Options>Language Exceptions.
Now Delphi works fine and don't need to reinstall it.
Reason for loosing my previous configuration that worked fine might be in copying my files from one folder to another (as well as config and other temp files) when paths became wrong and after that I probably deleted old config files and started with settings from beginning...
+1 Tip: If you get this message: [Error] RLINK32: Unsupported 16bit resource in file ....\estands\estandar_StdFormMainFrm.DFM problem is in Text-DFM option. When you right-click on the form in the IDE, is the menu item "Text-DFM" (or maybe called "Text as DFM") checked? If not, do so, save and try to compile.
If somebody knows reason for this behaviour, detailed explanation would be useful. Until now I found this option is for backwards-compatibility to older Delphi-versions.
I have a very simple Delphi 2010 dll that I load from a Visiual Studio 2008 C ATL console application (MVF GUI app does not work either). When I debug the console app from the IDE directly - no break points - the output from the application is not correct but when I run the app directly or if I attach to the process with the debugger then it works 100%. Debugging the same dll from a Delphi console app (i.e. running it from the IDE) also works.
The VS debugger seems to break the app depending on how you run it. VS2010 does the same!
I have made 100% sure - several times! - that the data types and calling convention of the dll exports and those in the console app match. I can go into more detail but I don't want to confuse the matter with what may be irrelevant information. Please tell me if I have to go into the specifics of the code if what I have offered is not enough.
Has anyone experienced this sort of thing and know how to fix it?
I've got similar problem once (different behavior in IDE/debugger and in standalone application). It turned out, that I've checked the value of unset variable. Debugger allocated it (always!) in previously used block of memory, such that the value was not empty and the application worked correctly (because only the conditional block was erroneous). However, OS sometimes put the application in empty memory block (filled with 0s), the condition failed and application crashed.
Maybe this is the issue? Try using OutputDebugString()'s to track down values of variables during the library runtime. Without some source code I believe, that it's not easy to say, what might be the reason.
Best regards -- Spook.