I followed this tutorial and got Eclipse to recognize the program I'm debugging.
However, after setting a break point, and steering the application to the break point, the application just seems to ignore it.
The code continues merrily as if nothing happened, and I don't get to see the variables I'm trying to look at.
Unfortunately I don't know what info to include here, so if you need more information, just let me know in the comments.
You have to be careful with what you are doing. There are some pitfalls when debugging node applications in eclipse. Here are some tips that might help you.
Start your application with node --debug-brk your-script.js
Start the debugger in eclipse
Step over (F6) the first few require statements, that import the code you want to debug.
Set your breakpoints. (Be sure you don't set breakpoints in the source files you are currently editing. When debugging, there is a "Project" in your workspace that contains all the scripts that are loaded by node. Set your breakpoints in some of these files. Otherwise the breakpoints will be ignored. Most often you want to set breakpoints at the beginning of a callback.)
Then resume (F8) the script and it will pause at the first breakpoint it passes.
Start with that until debugging works for the first time. After that you can try more unconventional cases.
Related
I'm building a flutter app in VsCode
When am ready to lunch my app
I use Run -> start debugging in vsCose
But alternatively I can use Run -> Run without debugging
So what the difference between the two?
In Debug mode, you can pause your application at so called break points. This can help you to find bugs in your code. You can also figure out, which values your variables consist at a speficic part in your application.
You can set a break point by double clicking on the left of a line number where you want to pause your code from running (see here: debug break point example)
Debug mode is for development. As such, the binaries are larger and slower, because they have e.g. the names of all your functions stored alongside line number information for debug tracing to work. Hot reloading is also an important feature of development or debug mode.
When you run in production mode, all the debug information is stripped away, the app loads much faster, and all debug information is elided from the binary that is produced. It is for end-use.
start debugging mean's in debug mode, it is best when you want to debug your app. you can set multiple break points and check what is value of that variable at particular point of time.
Run without debugging mean simple run where your break points doesn’t matter.
Moreinfo: https://flutter.dev/docs/development/tools/vs-code
When running my code in debug mode, I keep getting 2 error messages:
Could not delete [path_to]\productiondb.log. May be locked by another process
I don't know what process might be locking it. It comes when I make changes to the code while my Pivotal tc Server is running in debug mode, but it dosent seem to create a lot's of trouble. Sometimes however, I get this warning:
Also due to some changes. I usally just restart the server and move on. This isen't the real problem, the real problem is that I get these messages when I havent doen any changes. Somethimes it accures when I run a certen part of the code, other times i occurs when I open certen codes in sts, however, it doen't seem to stop at the same place twice.
I am suspecting that this has something to do with git. I am using git to change between versions and doing tests. So I am thinking that STS has some of the code in memory from before I changed branche with git, and isen't updating it before I run or open the file with that code. But I am rather new to both sts and git, and can't be certan that it would work that way. If it is, does anyone know how to update sts after I have changed branch? If it is not, does anyone know what might causing it?
If you run an app in debug mode, the Eclipse Debugger tells the application when code gets changed and tries to use the debug API to swap in the new code into the running application. This is especially useful if you debug your code, hit a breakpoint, step through the code, fit the issue, change the code, and press save. At that moment, the Eclipse compiler updates the class file and tells the running JVM to swap in the new code. If that succeeds, the debugger will jump back to the last stack frame and the execution of your app will continue with the beginning of the method that you entered. This allows you to directly continue to debug and step through the updated code without restarting the app.
While this is a great feature of the JVM, it is very limited in terms of what scope of changes to the classes the JVM can deal with while doing this hot-swap. It is usually limited to method implementations. So adding new methods, adding or deleting members of the class, etc, are not supported. As a result, the above screenshot will appear. It means that the JVM wasn't able to hot-swap the changed code and will continue to run with the previously loaded code instead of the changed one.
As the number of breakpoints builds up during a phase of development, or during debugging a single issue, it's usually necessary to clear all of the current breakpoints when moving to another issue/phase.
Is there a way to have a 2nd Breakpoints tab, where permanent Breakpoints could be left intact i.e. for intermittent issues we sometimes leave breakpoints active while fixing numerous other issues.... this makes clearing all Breakpoints a real hassle
Brian
P.S. I'm aware of using logging instead of these longer term breakpoints
You can group and assign breakpoints in working sets to achieve this:
In addition you may export or import them to transfer breakpoints between projects or store them with your project.
Friends,
I am building and debugging my xproj. Now the control is not stopping at the breakpoint i kept in the program but it is stopping at the return statement of operator++() in the stl_iterator.h file. After I press Continue the code is giving expected results but the thing is I cannot see the step by step debugging. Can any one give me clue why it is happening so, always i see the control at same position. I cleaned all targets and tried but no luck.
Active SDK = iphonesimulator4.0, Active Configuration = Build. (I used C++ in the code).
With iphoneSImulator3.1.2, i can able to debug step-by-step for the same code.
Thanks in Advance,
Anil
Sometimes the compiler will optimize your code and make breakpoints move around. Be sure to turn off all optimizations when building for debugging purposes; this should already be set in the “Debug” build setting.
I am SOOOOO discouraged. This seems so simple, but being a complete novice in Drupal and Eclipse PDT I have absolutely no idea where to look. My DAYS of searching seems to indicate that I am the only person on the planet with this problem.
Eclipse IDE for PHP Developers (1.2.1.20090918-0703)
WampServer Version 2.0
Apache 2.2.11
PHP 5.2.9-2
MySQL 5.1.33
Drupal 6.15
xDebug php_xdebug-2.0.5-5.2.dll
I setup my project in Eclipse to point to my Drupal directory (C:\wamp\www\drupal-6.15). I start the debugger (xdebug) and I stop at the first line of code. I can step through the code line by line -- so I think I am in the debugger, and when I terminate the app, I see the xdebug termination message in the tab heading.
But I cannot set a breakpoint in any of the PHP code files -- specifically a new .module file.
When I right click in the breakpoint column on the left in index.php (main) I see "toggle breakpoint" and the little blue circle next to the line of code...so I think I know how to set a breakpoint. But when I try to set a breakpoint in my .module, I see a menu that asks me to "add a bookmark" and no option to set a breakpoint.
Why can I not set a breakpoint in this file? Is my project path not set up correctly? Do I need to amend my include path? I can't get Eclipse to recognize even core modules not just site/all modules. I've seen posts about "importing" files into the project, and making sure the correct php.ini file is used for configuring xdebug. I'm lost.
There are so many posts about using Eclipst PDT and xDebug and they all end with "have fun debugging" or "just set some breakpoints and off you go" -- but what if you CAN'T set a breakpoint? Any ideas about where Eclipse is lost? Where in Eclipse can you get a list of files it has included in its build?
I think I just need to know understand why Eclipse cannot find these modules within the project (i.e. drupal application) path to allow me to set breakpoints. Then I think I can carry on. So discouraging...
Thanks to anyone listening.
Thanks for the tip. I think I had seen your similar response in another post somewhere.
Actually, the solution for me was to make sure to include all of the standard Drupal file extensions in the Eclipse file associations preferences: Preferences->General->Content Types->Text->PHP Content Type. The defaults are various *.php, *.phpX, *.phtml extensions, but not the extensions used in Drupal modules -- *.info, *.inc, *.module, *.install, etc.
Simple and obvious once you figure it out. I'm surprised with all the Eclipse-xDebug-Drupal setup instructions out there that this had not shown up. Lots of details about matching project paths with server paths, but nothing about this.
I hope my struggle helps someone. I did learn a lot about Eclipse PDT along the way :-). Good luck.
Breakpoints are tricky in PDT projects:
for php files, you need to be careful
One thing that gets me a lot is that there a lot of "invalid" places where you set breakpoints. You can put the dot there in the IDE, but the debugger won't stop at it:
blank/non-code lines
on switch statements
in some types of callbacks (for example, preg_replace)
But for breakpoints in .module files, this should be related to a setup issue.
I made the following changes to my setup:
Upgraded from php 5.2.1 to php 5.2.3
Installed the Zend debugger client in Eclipse/PDT (theoretically not necessary from what I understand, but I decided to give it a try)
Made sure that the Drupal files were fully imported into my project, not just referenced as include libraries.
I did that last step after I created a tiny test case and discovered that I could get the debugger to stop on a breakpoint in an externally included file only if that file was imported into the project, not if it was referenced as part of an include library directory.
To my mind this seems like a bug - the debugger could certainly see that the files in the include library directories were source files and it let me set breakpoints in them, so it seems that it should stop on them.
(For comparison from a separate (java) IDE, IntelliJ will let you define breakpoints in jar files as long as you tell it where the source is. Once you've defined it, it will stop on it.)
I think it was principally that last step that did the trick, so I'd suggest that anyone else with a similar problem make sure that isn't an issue in their setup first, and then try the other steps.
check whether you opened your java file in java editor mode.
ie ctrl+shift+R, in this popup check the button beside OPEN option and select java editor.
The problem of not being able to set a breakpoint can occur if you have recently created a file. You must close and re-open the file for it to be recognised as a source file that can be debugged, and to enable the code highlighting.