为什么我的调试器在视觉上以错误的方式停止？

时间：2017-05-03 16:48:08

标签： google-chrome debugging meteor webstorm

我正在使用

METEOR@1.4.4.2
WebStorm@2017.1.1 
Chrome@58.0.3029.110 (64-bit)
macOS Sierra 10.12.5
ecmascript@0.7.3
ecmascript-runtime@0.3.15

最近，调试器开始停在错误的行，但只是在视觉上，大多数情况下它就像实际断点后面的8-14行。

e.g。

*橙色条表示谷歌浏览器中的断点

控制台输出：

enter image description here

另外，正如您所看到的，某些行变暗，这意味着我无法在浏览器中设置断点。

WebStorm内部调试器中的行为相同。所以我认为这不是Chrome的错。看起来源映射已被破坏。我不知道是WebStorm，还是Meteor。在这种情况下，调试非常困难......

5 个答案:

答案 0 :(得分：9)

很难肯定地说，但您遇到的问题似乎与导致Meteor生成错误源地图的错误有关。

源地图

这不是浏览器的“错误”。它只显示项目中源映射传递给它的代码和位置。

app.js文件和源地图（app.js.map）由Meteor构建过程生成，并从.meteor/local/build/programs/web.browser/app目录提供。

.map文件负责告诉浏览器如何显示原始源，以及生成的app.js文件中的哪些段映射到原始源代码中的哪些段。

可以找到关于源地图技术方面的一个很好的解释here。

您可以在线查看源地图并查看使用this tool的地图（选择 custom ... 并拖放.js和.map文件。

疑似错误

作为构建过程的一部分，Meteor使用babel-compiler Meteor软件包。在某些时候，一个错误导致在babel转换后产生无效地图。

该错误目前正在tracked on GitHub，而流星人似乎正在接近原因。

你能做什么？

目前，没有快速简便的解决方法。

你可以：

  • 观看错误线程并等待它现在解析并调试，而不使用源映射（如果错误将很快修复，可能是最好的）。
  • 使用相关Meteor软件包的本地克隆（可以工作，我没有深入研究依赖性问题而不是真正推荐它，但是here's a way of doing it）。
  • 从处于已知良好状态的git checkout运行Meteor，直到修复程序被释放。

最后一个选项是@hwilson did，以便通过git bisect开始查明错误。

您可以参考Meteor developer document了解有关从结帐运行流星工具的方法的详细信息，但事情的要点如下：

首先，请确保您的代码（包括.meteor/versions和.meteor/packages）已签入源代码管理中，因为您可能需要暂时将其弄乱，并希望在错误后恢复它们是固定的。

  1. git clone --recursive https://github.com/meteor/meteor.git到您选择的目录（例如/home/yourname/src/remote。
  2. cd meteor。
  3. git checkout 25a89b5获取最后一次已知的好提交。
  4. git submodule update --init --recursive确保结帐后一切都仍然是黄金。
  5. ./meteor --help让检出的版本开始
  6. 在您的项目中，从.meteor/packages文件中删除版本信息，因为它们可能与您的结帐提供的信息不兼容。
  7. 在项目目录中，运行/home/yourname/src/remote/meteor/meteor run。

    8. 这将运行检出的Meteor版本。您可能需要执行meteor reset（警告：这会清除本地mongo数据库）或者至少清除一些.meteor/local（例如，源映射）以使其工作，但这可能是不必要的

    对于我认为将在不久的将来解决的错误，我付出了相当多的努力，但我决定将这些信息部分包含在内，以便用作未来源地图相关问题的文档。

答案 1 :(得分：1)

很难说肯定。在粗略的谷歌搜索中，看起来你并不是唯一一个看到这个的人。正如@MasterAM所提到的那样，可能是因为来自翻译的源地图。我不认为你可以做很多事情，但是你可以尝试清除看起来对某些人有效的浏览器和IDE缓存。

Javascript Stops at a line without a breakpoint in remote debug mode

Clearing Webstorm's cache

答案 2 :(得分：0)

不确定这种情况，但在使用eclipse调试java时遇到了类似的情况。当源代码和正在调试的编译/解释代码不同时，就会发生这种情况。

尝试调试一个简单的js代码来验证chrome＆＃js调试器本身是否有问题。如果它有效，那么对代码行的解释不是＆＃39; debug-enabled＆＃39;将是他们都在同一条线上（直到记录日志＆＃39;＃39;）。这也可以抵消浏览器中的行号。

这是一种可能的解释。

答案 3 :(得分：0)

我要补充一点，有时缩小的js文件的 Pretty-print 在调试模式下会在代码的实线和移位后的行之间添加偏移量（转换为Pretty-print）。

>

因此，请避免在模式调试中进行“漂亮打印”，您将挂在右行。

答案 4 :(得分：0)

为时已晚三年，但是如果有人钢铁有这个问题。 问题在于IDE和编译器对行分隔符的不同解释，它们会生成.map文件。 例如，在WebStorm和Angular-Project的窗口中-如果TypeScript编译器是Unix样式（仅 LF ），则忽略行分隔符。 在这种情况下，如果代码格式化程序将太长的行转换为几行较短的行，并仅通过 LF 拆分这些行，则在.map文件中，该原始单行将被解释为单行，但WebStorm将显示​​为 LF 将行分隔为不同的行。

解决方案-将行分隔符更改为CR + LF，问题将得到解决！

P.S。我想这是TypeScript编译器中的错误

相关问题
最新问题