我的网站 IE 总是崩溃,无法调试
我的网站突然开始使 Internet Explorer 崩溃。
网站加载并开始执行 javascript,但机器在某个地方爆炸了。我什至没有收到脚本错误,它只是崩溃了。我尝试使用内置调试器手动单步执行每一行 js,但问题当然不会发生。
如果我选择在应用程序崩溃时对其进行调试,我会看到以下消息。
iexplore.exe 中 0x6c5dedf5 处出现未处理的异常:0xC0000005:读取位置 0x00000090 时发生访问冲突。
调用堆栈中的前 5 项如下所示
VGX.dll!6c5dedf5()
[下面的帧可能不正确和/或丢失,没有为 VGX.dll 加载任何符号]
VGX.dll!6c594d70()
VGX.dll!6c594f63()
VGX.dll!6c595350()
VGX.dll!6c58f5e3()
mshtml.dll!6f88dd17()
VGX.dll 似乎是 vml 渲染器的一部分,实际上我正在使用 VML。我并不感到惊讶,因为我在 vml 方面遇到了很多问题,属性必须按特定顺序设置,有时当您将元素附加到 dom 时,您无法设置属性,反之亦然(顺便说一句,所有内容都未记录),但问题就来了通常可以在调试时重现,但现在不行:(
这个问题也会出现在无插件模式下。
是否有比反复试验更好的方法来解决这个问题?
编辑: 添加一个控制台来输出对 DOM 的每个可疑修改,使得该问题有时会发生。 (控制台也在同一页面上用 JavaScript 实现,即使在崩溃后我也能看到输出,因为窗口仍然可见)显然,这似乎是某种竞争条件。
我设法进一步追踪它,当您在刚刚添加对象后过快地从 DOM 中删除对象时,似乎就会发生这种情况。 (很可能仅适用于具有某些特殊属性的 vml-elements,没有进一步尝试)并且无法通过在removeChild前面添加死循环来修复它(无论如何都是非常糟糕的解决方案),页面必须由浏览器在addChild之后一次,然后才能调用removeChild。叹
I have a website that suddenly started to crash internet explorer.
The website loads and starts executing javascript but somewhere in there the machinery explodes. I don't even get a script error, it just crashes. I've tried to manually step through every single line of js with the built in debugger but then of course the problem doesn't occur.
If i choose to debug the application when it crashes i see the following message.
Unhandled exception at 0x6c5dedf5 in iexplore.exe: 0xC0000005: Access violation reading location 0x00000090.
The top 5 items in the call stack looks like this
VGX.dll!6c5dedf5()
[Frames below may be incorrect and/or missing, no symbols loaded for VGX.dll]
VGX.dll!6c594d70()
VGX.dll!6c594f63()
VGX.dll!6c595350()
VGX.dll!6c58f5e3()
mshtml.dll!6f88dd17()
VGX.dll seems to be part of the vml renderer and i am in fact using VML. I'm not suprised because i've had so many problems with vml, attributes has to be set in specific order, sometimes you cant set attributes when you have elements attached to the dom or vice versa (everything undocumented btw) but then the problems can usually be reproduced when debugging but not now :(
The problem also occurs in no plugin-mode.
Is there a better approach than trial and error to solve this?
Edit:
Adding a console outputting every suspect modification to the DOM made the problem only occur sometimes. (the console is also implemented in javascript on the same page, i'm able to see the output even after a crash as the window is still visible) Apparently it seems to be some kind of race condition.
I managed to track it down even further, and it seems to occur when you remove an object from the DOM too quickly after it's just been added. (most likely only for vml-elements with some special attribute, didn't try further) And it can't be fixed by adding a dead loop in front of removeChild(pretty bad solution anyway), the page has to be rendered by the browser once after the addChild before you can call removeChild. sigh
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
(老问题但很重要)
我遇到了一个非常相似的问题 - 包括许多复杂的 VML(来自 Raphael),而且看起来几乎不可能调试。
事实上,事实证明,最简单的低技术方法是最好的。这是一个显而易见的方法:我写在这里是因为有时当面对令人生畏的问题时,人们最后想到的就是显而易见、简单的解决方案。
因此,简单的老式调试:在每次远程要求或复杂的调用之前和之后进行大量
alert("1");
、alert("2");
等我的代码,提供超级简单可靠的断点,不依赖于任何可能本身崩溃的功能(例如开发人员工具)。然后,只需查看在崩溃之前收到的警报号码 - 问题一定出现在该警报和下一个警报之间。添加更多警报,直到将范围缩小到精确的行。就我而言,它实际上与复杂的 VML 无关 - 它是一个 for 循环,由于某种原因仅在 IE7 上无限地继续。
(old question but important one)
I had a very similar problem - including lots of complex VML (from Raphael), and it looked near-impossible to debug.
Actually, it turned out the simplest low-tech approach was the best. It's an obvious approach: I'm writing here because sometimes when faced with an intimidating problem the obvious, simple solutions are the last a person thinks of.
So, simple old-school debugging: Lots of
alert("1");
,alert("2");
etc before and after every remotely demanding or complex call in my code, giving super-simple reliable breakpoints that don't rely on any features (e.g. developer tools) that might themselves crash out. Then, just see which number alert you get to before it crashes - the problem must arise between that alert and the next one.Add more alerts until you narrow it down to the exact line. In my case, it was actually nothing to do with the complex VML - it was a for loop that, for some reason was continuing infinitely only on IE7.
停止使用 VML?
如果您在 IE 中需要的东西确实无法通过移动、缩放、裁剪和替换图像来完成,那么请考虑使用 Flash、Silverlight 或类似工具。
如果您的生活依赖于 VML,那么请尽可能多地阅读其他人的经验,这可能会简化试错方法。
Stop using VML?
If you need stuff in IE that really can't be done by moving, scaling, cropping and replacing images, then consider using Flash, Silverlight or similar.
If your life depend on VML then read as much as possible about other peoples experience, that may ease the trial and error approach.
它是一个空指针取消引用不可利用的崩溃
Its a null pointer dereference non exploitable crash
确保您的脚本在 DOMReady 事件发生后正在运行。 IE 因在完全加载 DOM 之前修改 DOM 时崩溃而臭名昭著。
在某些情况下,IE 可能会过早触发 DOMReady 事件。有关如何解决此问题的更多信息,请参阅此处和此处 。
Make sure that your scripts are running after the DOMReady event occurs. IE is notorious for crashing when modifying the DOM before it is fully loaded.
In some instances IE might prematurely fire the DOMReady event. See more information on how to overcome this here and here.
您是否以任何形式使用 JSONP?像 jQuery 这样的流行实现倾向于在运行后通过从 DOM 中删除脚本节点来尝试清理内存。我在很多情况下都看到过 Internet Explorer 崩溃的情况。永远无法弄清楚需要什么其他条件才能导致崩溃。我的其他页面上发生的事情太多了。
无论如何,如果您使用 jQuery.getJSON,请检查 jquery 源中的以下行:
(jquery 1.4.3 上的第 5556 行):
您可以安全地删除它,或者将其设置为仅在非 IE 浏览器中发生。
希望这有帮助。
Are you using JSONP in any form? Popular implementations like jQuery tend to try and clean up memory by deleting the script node from the DOM after it has run. I've seen that crash Internet Explorer in many cases. Never could figure out what other conditions needed to be around to cause that to crash. Too much stuff going on in my other pages.
Anyhow, if you're using jQuery.getJSON, check the following line in jquery source:
(line 5556 on jquery 1.4.3):
You can safely remove that, or conditionalize it to only happen in non-IE browsers.
Hopefully that helps.