Chrome Development Tool: [VM] file from javascript

Asked 28/6, 2013 at 14:50 Answered 13/2, 2020 at 11:22

190

I added a breakpoint in my javascript file (jaydata.js) and was pressing "Step over to the next function call." When it got to a line that was:

},

another file titled "[VM] (8312)" popped up. I kept clicking "Step over to the next function call" and now my screen is:

enter image description here

What are these strange and mysterious scripts titled "[VM](XXXX " and where do they come from?

Evangelina answered 28/6, 2013 at 14:50 Comment(2)

These VM files also appear when you are editing files which are debugging at the same time. Chrome loses synch and when a breakpoint is put on the file it will stop the code at some other position in the file in memory somewhere. e.g. test.html will allow a breakpoint but when Chrome stops it does so at VM99:test.html at some other position. The solution is to close Chrome rename the files, e.g. test2.html, and start again. (Clearing history, cache etc doesn't work and Chrome will keep loading the VM99:test.html if you try that. – Estriol 16/12, 2016 at 12:46

@Estriol what if this happens with any browser? – Chamfer 21/1, 2021 at 14:0

140

[VM] (scriptId) has no special meaning. It's a dummy name to help us to distinguish code which are not directly tied to a file name, such as code created using eval and friends.

In the past, all of these scripts were just labelled (program).

If you're interested, just look up "[VM]"in the source code of Chromium, you will discover that these numbers have no significant meaning outside the developer tools.

update 2015-06-25

[VM] (scriptId) was renamed to VMscriptId a while ago, and here is the direct link to search result in case the value changes again.

Aldo answered 28/6, 2013 at 20:52 Comment(6)

Would Chrome hit the [VM] file instead of the live js file? If so, why? – Martellato 2/10, 2013 at 14:46

@Martellato What do you mean by "Hit the [VM] file instead of the live js file"? – Aldo 2/10, 2013 at 20:42

@RobW disregard; my browser was caching the js file (despite having updated my cache buster). – Martellato 4/10, 2013 at 13:48

[VM] (scriptId) was renamed to VMscriptId a while ago, but I've kept the answer in its current state to not invalidate the question. The latest codesearch link is: cs.chromium.org/%22VM%5C%22%20+%22 (direct link to search result in case the value changes again: chromium.googlesource.com/chromium/blink/+/…) – Aldo 25/6, 2015 at 17:25

I recently encountered this problem without any eval - it appears to be related to the use of iFrames. My evidence for this is that when I set a breakpoint on code in an iFrame, I get the [VM] problem, but when I open the iFrame in its own window, I get hit the breakpoint just fine. Just sure if this qualifies as one of eval's "friends" as described in the answer. – Grant 2/6, 2016 at 19:44

@Grant did you fix that somehow? I'm having the same issue and this VM thing is causing some code being called twice. – Martellato 6/10, 2022 at 14:33

Whenever you load HTML content through AJAX, and that content contains <script> tags, the script will be evaluated using eval() and recognized by Chrome's Sources view as a new file beginning with 'VM'. You can always go to the Network tab, find the AJAX request, and view the HTML response in its entirety, including your script.

Kamal answered 5/5, 2014 at 14:43 Comment(3)

This sucks for debugging though. If I use a script tag with src=/test.js then cause an error that traces back to test.js, the traceback contains the correct filename, but thereafter, stacktraces contain the VM magic. This makes it impossible to get the source code [from same origin] for the files in the stacktrace more than once, and you can't cache them, as you don't know which file is which in future stacktraces. This is fixed in Dev Tools, but not in webapps. – Organography 19/6, 2014 at 13:45

This is probably the most common reason it happens in modern web applications, and another good example of why we should separate code from content. – Portaltoportal 29/6, 2020 at 21:34

Just to add an example that caused the VM (scriptId) situation in my case: $('head').append('<script type="text/javascript" src="site.js"><\/script>'); – Perusal 17/8, 2022 at 11:51

When using eval, the javascript gets thrown into the Chrome Debugger VMs. In order to view js created with eval under Chrome Debugger Sources, set this attribute at the end (thanks Splaktar) of the js:

//# sourceURL=dynamicScript.js

Although @ may still work instead of #, # is what the spec prefers.

Is possible to debug dynamic loading JavaScript by some debugger like WebKit, FireBug or IE8 Developer Tool?

Plethora answered 4/9, 2013 at 18:45 Comment(1)

That trick also works well for script injected via document.createElement('script'); – Eberhardt 9/2, 2016 at 15:15

If you want to debug programmatically injected JS files in chrome you can use the debugger; statement, this is faster than finding where your script is and also faster than generating a file with sourceurl.

It works like a breakpoint and automaticaly pinpoints your code in the chrome source tab wherever you use the debugger; statement.

Note that the source of the script is a VMXXX file.

Prosaism answered 29/5, 2018 at 20:16 Comment(5)

This doesn't appear to answer the question. – Vereeniging 29/5, 2018 at 20:40

My bad, I let myself go by the other answers to this question. – Guernsey 30/5, 2018 at 4:30

Super! This is exactly what I was seeking for. No need to find out in which VM your code was inserted by JS engine. – Shahjahanpur 15/5, 2019 at 14:10

what's the connection between this answer and the question? – Christa 9/10, 2019 at 7:22

With the debugger; statement he can demystify where the mysterious 'strange and mysterious scripts titled "[VM](XXXX "' are comming from if he wishes so. – Guernsey 10/10, 2019 at 16:1

I found VM gets generated from some Chrome extensions - they insert CSS/JS into the page and Chrome uses the VM files to run it.

Racine answered 19/5, 2015 at 9:2 Comment(1)

That's what it was in my case. So GLAD to see those pesky "VNxxxx" "source" tabs gone. They were being created either by React Developer Tools, Google Sheets, Google Docs Offline, or Redux Dev Tools. – Cohlier 9/7, 2023 at 22:22

When you're debugging a child window (iframe) source which is subsequently unloaded your source file will also get the VM prefix and the yellow background.

Rountree answered 26/10, 2017 at 13:40 Comment(0)

I had the same issue when I was debugging my angular application. Seeing too many VM scripts which could not be blackboxed were really taking long to debug. I rather chose mozilla/IE explorer to debug.

Perrault answered 28/3, 2018 at 4:31 Comment(1)

No VMxxx in Firefox. This is the only working solution so far. – Damned 27/4, 2021 at 15:6

for prevent this

(function ()
 {
  var originalEval = eval;
  eval =
   function (script)
   {
    return originalEval(script + "\n//# sourceURL=blackbox-this.js");
   }
 }());

And then blackbox ^.*blackbox-this.js$

Same for setInterval/setTimeout when it gets a string (but that is a bad practice anyway, right? ;))

Does that work for you?

Matazzoni answered 13/2, 2020 at 11:22 Comment(0)

I ran into the same problem. The issue is that my app's code was considered blackboxes by accident. When I tried to step into the code, it kept opening these VMXXXX tabs.

After removing the blackbox setting for my app's js file, I could successfully step through my code.

Contiguity answered 23/2, 2018 at 22:12 Comment(3)

I have the same problem, what did you do exactly? – Chamfer 21/1, 2021 at 13:4

Sorry @sTx, I simply don't remember any of this. – Contiguity 22/1, 2021 at 6:49

No problem, in my case was a nullreference bug in my code. – Chamfer 22/1, 2021 at 6:52

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

update 2015-06-25

Recommended topics

Hot tags