Chrome Development Tool: plik [VM] z javascript

139

Dodałem punkt przerwania do mojego pliku javascript (jaydata.js) i naciskałem „Przejdź do następnego wywołania funkcji”. Kiedy dotarło do linii, która brzmiała:

},

pojawił się inny plik zatytułowany „[VM] (8312)”. Ciągle klikałem „Przejdź do następnego wywołania funkcji”, a teraz mój ekran to:

wprowadź opis obrazu tutaj

Co to za dziwne i tajemnicze skrypty zatytułowane „[VM] (XXXX”) i skąd się one biorą?

debugging google-chrome-devtools

— AllieCat
źródło

1

Te pliki maszyn wirtualnych pojawiają się również podczas edycji plików, które są debugowane w tym samym czasie. Chrome traci synchronizację i kiedy punkt przerwania zostanie umieszczony w pliku, zatrzyma kod w innym miejscu w pliku gdzieś w pamięci. np. test.html zezwoli na punkt przerwania, ale kiedy Chrome się zatrzyma, robi to na VM99: test.html w innym miejscu. Rozwiązaniem jest zamknięcie Chrome, zmiana nazwy plików, np. Test2.html, i rozpoczęcie od nowa. (Czyszczenie historii, pamięci podręcznej itp. Nie działa, a Chrome będzie nadal ładować VM99: test.html, jeśli spróbujesz.

— QuentinUK

112

[VM] (scriptId)nie ma specjalnego znaczenia. Jest to fikcyjna nazwa, która pomaga nam odróżnić kod, który nie jest bezpośrednio powiązany z nazwą pliku, na przykład kod utworzony przy użyciu evali znajomych.

W przeszłości wszystkie te skrypty były po prostu oznaczone (program).

Jeśli jesteś zainteresowany, po prostu spójrz "[VM]"na kod źródłowy Chromium , a odkryjesz, że te liczby nie mają znaczącego znaczenia poza narzędziami programistycznymi.

aktualizacja 2015-06-25

[VM] (scriptId)została zmieniona na VMscriptId jakiś czas temu , a tutaj jest bezpośredni link do wyniku wyszukiwania na wypadek ponownej zmiany wartości.

— Rob W
źródło

1

Czy Chrome trafi do pliku [VM] zamiast do pliku live js? Jeśli tak, dlaczego?

— Matt

@Matt Co masz na myśli mówiąc „Uderz w plik [VM] zamiast w live js”?

— Rob W

@RobW lekceważenie; moja przeglądarka buforowała plik js (pomimo aktualizacji mojego narzędzia do usuwania pamięci podręcznej).

— Matt

1

[VM] (scriptId)została zmieniona na VMscriptId jakiś czas temu , ale zachowałem odpowiedź w jej obecnym stanie, aby nie unieważnić pytania. Najnowszy link do wyszukiwania kodów to: cs.chromium.org/%22VM%5C%22%20+%22 (bezpośredni link do wyniku wyszukiwania na wypadek ponownej zmiany wartości: chromium.googlesource.com/chromium/blink/+/… )

— Rob W

Niedawno napotkałem ten problem bez żadnej oceny - wydaje się, że jest on związany z użyciem iFrame. Dowodem na to jest to, że kiedy ustawiam punkt przerwania w kodzie w iFrame, pojawia się problem [VM], ale kiedy otwieram iFrame w jego własnym oknie, trafiam w punkt przerwania. Po prostu upewnij się, że kwalifikuje się to jako jeden z „przyjaciół” evala, jak opisano w odpowiedzi.

— Danger

42

Za każdym razem, gdy ładujesz zawartość HTML przez AJAX, a ta treść zawiera <script>tagi, skrypt zostanie oceniony za pomocą funkcji eval () i rozpoznany w widoku Źródła Chrome jako nowy plik zaczynający się od „VM”. Zawsze możesz przejść do zakładki Sieć, znaleźć żądanie AJAX i wyświetlić całą odpowiedź HTML, w tym swój skrypt.

— Sam Kauffman
źródło

3

To jest do bani debugowania. Jeśli src=/test.jsużyję tagu skryptu z, a następnie spowoduję błąd, który prowadzi do pliku test.js, plik traceback zawiera poprawną nazwę pliku, ale później ślady stosu zawierają magię maszyny wirtualnej. Uniemożliwia to pobranie kodu źródłowego [z tego samego źródła] dla plików w stacktrace więcej niż jeden raz i nie możesz ich buforować, ponieważ nie wiesz, który plik jest który w przyszłych stacktrace. Zostało to naprawione w narzędziach deweloperskich, ale nie w aplikacjach internetowych.

— Carl Smith

Jest to prawdopodobnie najczęstszy powód, dla którego zdarza się to w nowoczesnych aplikacjach internetowych i kolejny dobry przykład, dlaczego powinniśmy oddzielić kod od treści.

— alexw

37

Podczas korzystania z eval kod javascript jest wrzucany do maszyn wirtualnych Chrome Debugger. Aby wyświetlić js utworzony za pomocą eval w Chrome Debugger Sources, ustaw ten atrybut na końcu (dzięki Splaktar) js:

//@ sourceURL=dynamicScript.js

Czy możliwe jest debugowanie dynamicznego ładowania JavaScript przez jakiś debugger, taki jak WebKit, FireBug lub IE8 Developer Tool?

— Kalać
źródło

9

Składnia uległa zmianie, teraz: // # sourceURL = dynamicScript.js

— ThiagoPonte

1

Powinien również znajdować się na końcu JavaScript, a nie na początku.

— Splaktar,

Szukałem czegoś takiego. Dzięki

— David Kierans

Dziękuję Ci! To takie przydatne!

— Wigilia czerwca

4

W narzędziach do debugowania Firefoksa jest napisaneUsing //@ to indicate sourceURL pragmas is deprecated. Use //# instead

— Nighto

6

Jeśli chcesz debugować programowo wstrzyknięte pliki JS w chrome, możesz użyć debugger;instrukcji, jest to szybsze niż znalezienie skryptu, a także szybsze niż generowanie pliku z sourceurl .

Działa jak punkt przerwania i automatycznie wskazuje twój kod na karcie źródła chrome, gdziekolwiek używasz debugger;instrukcji.

Zwróć uwagę, że źródłem skryptu jest plik VMXXX.

— Rodrirokr
źródło

To nie wydaje się odpowiadać na pytanie.

— Grant Miller

Moja wina, pozwoliłem sobie na inne odpowiedzi na to pytanie.

— Rodrirokr

1

Wspaniały! To jest dokładnie to, czego szukałem. Nie musisz wiedzieć, w której maszynie wirtualnej Twój kod został wstawiony przez silnik JS.

— Oleg Bolden

jaki jest związek między tą odpowiedzią a pytaniem?

— Ravindra Thorat

Za pomocą tego debugger;stwierdzenia może zdemistyfikować, skąd pochodzą tajemnicze „dziwne i tajemnicze skrypty zatytułowane„ [VM] (XXXX ”), jeśli sobie tego życzy.

— Rodrirokr

4

Odkryłem, że maszyna wirtualna jest generowana z niektórych rozszerzeń Chrome - wstawiają one CSS / JS na stronę, a Chrome używa plików VM do jej uruchomienia.

— Mola
źródło

0

Podczas debugowania źródła okna podrzędnego (iframe), które jest następnie usuwane, plik źródłowy otrzyma również prefiks maszyny wirtualnej i żółte tło.

— JosdeHa
źródło

0

Napotkałem ten sam problem. Problem polega na tym, że kod mojej aplikacji został przypadkowo uznany za czarne skrzynki. Kiedy próbowałem wejść do kodu, ciągle otwierał te VMXXXXkarty.

Po usunięciu ustawienia czarnej skrzynki dla pliku js mojej aplikacji mogłem pomyślnie przejść przez kod.

— Justin Noel
źródło

0

aby temu zapobiec

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

A potem czarna skrzynka ^.*blackbox-this.js$

To samo dotyczy setInterval / setTimeout, gdy otrzyma ciąg znaków (ale i tak jest to zła praktyka, prawda?;))

Czy to Ci pasuje?

— RahmanRezaee
źródło

-1

Miałem ten sam problem, gdy debugowałem moją aplikację kątową. Widzenie zbyt wielu skryptów maszyn wirtualnych, których nie można było umieścić w czarnej skrzynce, trwało naprawdę długo. Do debugowania wolę raczej przeglądarkę Mozilla / IE.

— Sameeksha Kumari
źródło