I have the debugger running and It seems to work on first load as it hits breakpoints. However, as the user takes actions, the breakpoints are no longer hit.
I have this (notice how the line numbers are different. I'm guessing the minified/concat files of my actual JS doesn't match the files I'm debugging but I don't know how to change them)
but the console shows it on a different line for my log statement:
However, every time I try to debug, I miss the break point even though WebStorm sees the console messages in the debug console tool.
How can I debug code that is minified?
I did find the way to make this work in the end and it had to do with my sourcemaps for webpack. Because I was building a different directory, I had to point it to my build dir rather than my actual code for the webpack///./
http://puu.sh/pzyhA/ef2af3a74e.png
Related
[The Past] (that I could cope with, get around by): from time to time I used to run into a problem in which Chromium Developer Tools would not associate running code with the actual files it downloaded. At least that's how it 'feels'.
The code file would not be visible from the Google Dev Tools even though the code would be executing. If, one tapped the 'browse-files' icon - the file would not be on the list. Thus there would be no way to place a breakpoint and debug the file.
The work around that used to work for me. When this happened I usually tracked the source of code by messages written into the Console Terminal as Chromium would indicate the source of its invocation (of console.log()) right next the logged message. The name of the 'file' would usually be some random thing. So, no wonder breakpoints were not being hit as it turned out that for some reason Chromium deemed not 'swarm.js' to be executing but some random 'VM2231~.js' - with 'dynamic files?' always following the 'VM[NUMBER]' pattern - for whatever the reason.
Anyway, the 'workaround' used to work. Around the case of files not being listed within the Developer Tools, at least. So back then I ended up debugging files looking like so:
Present Case:
But, today even that ceased to work for me.
All of the sudden, breakpoints are neither being hit nor am I able to see the source of code triggering console.log() invocations as these happen - for some of the code files.
Notice below that for some invocations - the source is simply not depicted to the right. If I place breakpoints within the corresponding file, these breakpoints would never be hit, as well.
In short:
breakpoints are not being hit.
the source of console.log() invocations for some of the source files is not depicted, at all.
Thus, the code executes, still I'm unable to work further as I'm unable to debug.
If that helps anything, these are JavaScript modules, loaded dynamically at runtime.
I'm very new to debugging JavaScript, let alone Typescript, let alone a Stencil project that uses tsx files (which I assume are a certain type of reactive Typescript files).
I hoped that by adding a debugger statement into the code, using a refresh in Chrome the Debugging tools would show up. But nothing happens. If I add a console.log at the same place, it behaves as expected. But nothing happens with a debugger statement.
What to do? I don't want to debug with tons of console.log everywhere. 😏
I'm using VSCode by the way. Don't know whether that is relevant. I read in https://github.com/microsoft/vscode-js-debug that JavaScript debugging should be built into VSCode. I don't care whether I debug inside VSCode or inside Chrome - as long as I am able to debug somehow.
Here is the repository, if somebody wants to give it a try or checkout configuration files: https://github.com/NothingAG/adg-components
Thanks a lot.
Instead of adding debugger statements in code you can always add breakpoints in Chrome Developer Tools.
Load your app in the browser
Open Developer Tools in Chrome (for example right-click on a page and choose "Inspect")
In Developer Tools choose tab "Sources"
Open the file you want to debug by hitting command-P. An input field appears where you can enter the name of the file you want to debug
Add a breakpoint by clicking on the line number in the gutter
Next time your app hits the breakpoint the debugger shows up.
Apparently the build tool (nx) runs a production build which is why debugger statements are automatically filtered out.
To fix it you can explicitly instruct Stencil to run a development build:
npm start -- --dev
I'm trying to debug an AngularJS app in Chrome (with the Jetbrains extension) within Webstorm 8. It's working just fine, but the only naggy thing is that the actual file that has breakpoints in it doesn't get debugged, but a readonly copy that reads as the full url of the file is (see screenshot). It works, but I cannot edit the readonly file while moving from line to line.
edit: plus, the IDE usually shows an outdated version of my JS file and I have to manually refresh it to see the correct one.
The Webstorm Run/Debug config for Javascript is really straight forward, basically just the URL to the app.
Does anyone knows how to avoid this?
Cheers
The short answer is: you can't
The longer answer is, the computer is not running the code that you see on the screen, that's just what the debugger is showing you. The computer is actually running optimized, non-human-readable Javascript bytecode, which is created when you start your JS program, after syntax is checked, namespaces are created and memory is allocated for variables etc. You can't edit that bytecode by writing JS code directly, at least not with any debugger I know of (and I'm fairly certain you can't with Webstorm specifically; I use PHPStorm and its Javascript debugger).
Such problems usually mean that remote files are not correctly mapped to local ('remote URL' not correctly set for local files in Run configuration), so the debugger can't map the files being executed to your actual sources. I'm not sure what your application looks like... But, as Angular apps structure is more or less standard, I can suggest mapping the 'app' folder to 'http://localhost:9000' in javascript debug run configuration you are using to debug your angular code
I have a single process node.js application, which I wish to debug with Intellij IDEA 11 32 bits (node.js is 32 bits too).
So, I place an initial breakpoint and run. The debugger stops at the breakpoint, but then it refuses to do any of the following:
step into
go to another breakpoint
pause execution
When I step into, it seems just to run, without stepping through the code. Once running, it ignores any subsequent breakpoints and does not break when I press the pause button.
This issue drives me crazy.
Any ideas on how should I troubleshoot it?
EDIT
More info. After IDEA breaks on the first breakpoint (the only successful time) I try to inspect the variables and am unable to see any. IDEA is stuck on "Collecting data..." The watch window does not work too.
EDIT2
Justed posted an issue to their bug tracking system - http://youtrack.jetbrains.com/issue/IDEA-112925
I've been noticing that IntelliJ's node.js debugger kinda sucks. It's death by 1000 cuts. I love IntelliJ to death, its such a nice IDE. But for node, the debugger has a million different scenarios where breakpoints don't work properly, and another million where it doesn't properly give you access to the in-scope variable values, and another million where it doesn't step properly...
I'm gonna hafta try looking for another tool..
UPDATE 2014-01-13: I've been using IntelliJ's debugger for a while now (having found no other good tool). It seems some of the problems with it are problems with node or v8 itself. Most of the problems I was having have either actually been solved by newer versions of IntelliJ, or by using this workaround:
1. create a file called proxyDebug.js
2. put the following content in it:
require('path/to/the/script/you/want/to/debug.js')
3. point your debugger to that file
Apparently the node.js debugging hooks go buggy at the entrypoint script, so by creating this proxy entrypoint that we don't care at all about, there won't be any weird bugs caused by that in the scripts you do care about. The bugs this workaround fixed were missed breakpoints, predefined variables (exports, module, process, etc) being inaccessible by the debugger, and one or two other things I can't remember.
Last WebStorm version I tried (7.0.3) actually takes ages in collecting data but eventually works. If it seems stuck to you, try to leave it for a minute
I have a page that has a byzantine amount of JavaScript code running. In Internet Explorer only, and only version 8, I get a long-script warning that I can reliably reproduce. I suspect it is event handlers triggering themselves in an infinite loop.
The developer tools are limping horribly under the weight of the script running, but I do seem to be able to get the log to tell me what line of script it was executing when I aborted, but it is inevitably some of the deep plumbing of the ExtJS code we use, and I can't tell where it is in my stack of code.
A way of seeing the call stack would work, but preferably I'd like to be able to just break into the debugger when I get the long script warning so I can just step through the stack.
There is a similar question posted, but the answers given were for a not-the-right-tool, or the not terribly helpful advice to eliminate half my code at a time on a binary hunt for the infinite loop. If my code were simple enough that I could do that, it probably wouldn't have gotten the infinite loop in the first place. If I could reproduce the problem in Firebug, I'd probably be a lot happier too.
Here is what I would do:
Go to http://www.microsoft.com/whdc/devtools/debugging/default.mspx and install the Debugging Tools for Windows. You want to run WinDBG when this is installed.
Follow the steps outlined at http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx#a to setup the symbol server connection and have the symbols automatically downloaded to your local drive (c:\websymbols -- or whatever).
Run IEXPLORE.EXE under WinDBG. The help file should give you assistance in doing this if necessary. You need a couple of commands once you get Internet Explorer running and such. First, go ahead and get that large script going.
Break into the debugger (CTRL-SCROLLLOCK to break).
a. Do a LN to "list nearest" to get the DLL files that are loaded. Hopefully, you'll have JSCRIPT.DLL loaded in memory.
b. Type .reload /f to force the reloading of all of the symbols. This will take a while. Now, after this is done, type LN again and you should see that the proper JSCRIPT.PDB has been downloaded to your system in the symbols directory you setup earlier.
Depending on what you want to do, you may need to restart the debugger, but you can do this: After the initial break on WINDBG load, you can type "sxe ld jscript.dll" and it will break when jscript.dll loads.
This is the tricky part, because once this loads, you don't have the code for jscript.dll, but you have the proper symbols (if they are not loaded, then reload them with .reload /f). You can view the functions available by typing "x!jscript" and you'll get a full list of all of the functions and variables.
Pick one, set a break point, and then you should be able to track what is happening to your script.
If nothing else is accomplished, by using the .reload /f process, you can get the appropriate jscript.pdb files loaded on your system. It's possible you could use these in conjunction with Visual Studio to do additional debugging in that manner, but I'm not so sure how well that will work.
I've run in to this before and have had some luck with enabling the developer tools along with Visual Studio. When an error is encountered the page loading is halted, and I could then load up Visual Studio to see the specific line causing the trouble.
This site has some information on using Visual Studio along with the Internet Explorer debugger: Using Visual Studio to Debug JavaScript in IE