1

http://www.idea-palette.comをご覧ください。

上部のナビゲーションを使用してフェードインしているページが複数あります。ユーザーが上記のボタンのいずれかをクリックして、jQuery サイクル プラグインを使用するスライドショーを含む別のページにフェードインすると、IE7 がクラッシュします。

スライドショーのフェードを制御する jQuery をコメント アウトすると、IE7 がクラッシュしなくなりました。ここで確認できます: http://www.idea-palette.com/IEindex.php

すでにフェードしている他のコンテンツを含むコンテンツにフェードするとき、IE7はそれを好まないと思います。この 2 つを一緒に使用すると、何らかの形で IE7 が過負荷になるため、クラッシュすると思います。

jQuery サイクル プラグインがページのクラッシュを引き起こしていることを突き止める前に、なぜこれが起こったのかを尋ねました ( IE で私のウェブサイトがクラッシュするのはなぜですか? )。

DirectX フィルターと関係があります (おそらく何がフェードを行っているか)。これがスタックで、EAX は NULL です。コードが何をしていても、EAX を逆参照しようとしています。

CDXTFilterBehavior::_ClearSurface: 6C8E87E1 mov edi,edi 6C8E87E3 push ebp
6C8E87E4 mov ebp,esp 6C8E87E6 push ecx
6C8E87E7 mov eax,dword ptr [ebp+0Ch] 6C8E87EA mov ecx,dword ptr [eax] <NU--- LL EAX

dxtrans.dll!CDXTFilterBehavior::_ClearSurface()
dxtrans.dll!CDXTFilterBehavior::_DrawUnfilteredElementLayers()
dxtrans.dll!CDXTFilterBehavior::_DrawElementWithProceduralSurfaces()
dxtrans.dll!CDXTFilterBehavior::_ExecuteFilterChain()
dxtrans.dll!CDXTFilterBehavior::Draw()
mshtml.dll!CPeerHolder::Draw()
mshtml.dll!CLayout::DrawClientLayers()
mshtml.dll!CDispContainer::DrawSelf()
mshtml.dll!CDispNode::Draw()
mshtml.dll!CDispContainer::DrawChildren()
mshtml.dll!CDispContainer::DrawSelf()
mshtml.dll!CDispNode::Draw()
mshtml.dll!CDispContainer::DrawChildren()
mshtml.dll!CDispContainer::DrawSelf()
mshtml.dll!CDispNode::Draw()
mshtml.dll!CDispContainer::DrawChildren()
mshtml.dll!CDispContainer::DrawSelf()
mshtml.dll!CDispNode::Draw()
mshtml.dll!CDispContainer::DrawChildren()
mshtml.dll!CDispContainer::DrawSelf()
mshtml.dll!CDispNode::Draw()
mshtml.dll!CDispContainer::DrawChildren()
mshtml.dll!CDispContainer::DrawSelf()
mshtml.dll!CDispNode::Draw()
mshtml.dll!CDispRoot::DrawEntire()
mshtml.dll!CDispRoot::DrawRoot()
mshtml.dll!CView::RenderView()
mshtml.dll!CDoc::OnPaint()
mshtml.dll!CServer::OnWindowMessage()
mshtml.dll!CDoc::OnWindowMessage()
mshtml.dll!CServer::WndProc()
user32.dll!_InternalCallWinProc@20()
user32.dll!_UserCallWinProcCheckWow@32()
user32.dll!_CallWindowProcAorW@24()
user32.dll!_CallWindowProcW@20()
user32.dll! _InternalCallWinProc@20()
user32.dll!_UserCallWinProcCheckWow@32()
user32.dll!_DispatchClientMessage@20()
user32.dll!_fnDWORD@4()
ntdll.dll!_KiUserCallbackDispatcher@12()
user32.dll!_NtUserDispatchMessage@4()
user32.dll!_DispatchMessageWorker@8()
user32.dll!_DispatchMessageW@4()
ieframe.dll!CTabWindow::_TabWindowThreadProc()
kernel32.dll!@BaseThreadInitThunk@12()
ntdll.dll!_RtlUserThreadStart@8()
ntdll.dll!_RtlUserThreadStart@8()

おそらく、変換がまだ処理されている間に DOM から要素を削除していますか?'

この問題を解決する方法を知っている人はいますか?

4

1 に答える 1

2

前回投稿したときにコメントで述べたように、IEをリモートでクラッシュさせることができる場合は、Microsoftに連絡する必要があります。この脆弱性は、少なくともサービス拒否攻撃につながる可能性があり、リモートコード実行またはリモートルートにつながる可能性があります（Webページがオンデマンドでブラウザをクラッシュさせるバグは、攻撃者が信頼できないコードを実行できるように悪用される可能性が高いですあなたのマシン上で）。ここの人々はあなたがあなたの問題を回避するのを手伝うことができるかもしれませんが、彼らが根本的なバグを修正できるように、マイクロソフトは本当に知らされるべきです。

編集：自分の問題を回避しようとするためにも、バグを報告するためにも、問題を最小限のテストケースに減らすようにしてください。バグを再現するのに十分な要素の最小限のセットにすべてのコンテンツを削除します。次に、コードで同じことを行います。1つまたは2つの画像と、問題を引き起こすクロスフェードだけで、他に何も存在しないテストケースを取得するように努める必要があります。

次に、はい、バグを報告するには、最小限のテストケースへのリンクを送信します（または、可能であれば、バグレポートにインラインで含めます）。これはリモートのサービス拒否の脆弱性であり、リモートでコードが実行される可能性があるかどうかわからないことに言及してください。

そして、私が述べたように、これを最小限の例に減らすことは、バグを回避するのに役立つはずです。少なくとも、サイト全体で多くのことが行われているので、誰も実際に掘り下げたくないと感じるよりも、最小限のコード例でここで助けを得る可能性が高くなります。

于 2009-04-08T04:24:00.383 に答える