原文地址：http://blogs.msdn.com/tess/archive/2006/10/10/asp.net-Crash-_2D00_-Crazy-looping-in-a-SiteMap.aspx
發布時間：Tuesday, October 10, 2006 4:10 PM
作　　者：Tess      

一天，我收到了一封有關我的博客的郵件，提出如下問題，簡述如下：
 
我想快速地創建一個站點地圖，因此我重寫了BuildSiteMap()方法，在里面我寫了一個循環，用以添加一些仿造的sitemap節點。

public override SiteMapNode BuildSiteMap(){
   for (int i = 0; i < 5; i++)
      myRoot.ChildNodes.Add(new SiteMapNode(this, i.ToString(), i.ToString(), i.ToString()));
   return myRoot;
}

運行程序，就發生堆棧溢出，服務器也崩潰了。我用調試器單步調試，發現真的很奇怪: 

1) int i = 0
2) i < 5
3) myRoot...
4) int i = 0
5) i < 5
etc.

i的值看起來從來沒有增加，除非我調用到SiteMapNode（access a PRoperty, call a method），看起來這個循環是正確的。
是什么使得這個循環不確定呢？咋看可能是編譯器或者是CLR的一個bug.

(當我獲此問題時，我真不知道ASP.NET2.0中的站點導航，但我找到了這些文章... http://weblogs.asp.net/scottgu/archive/2005/11/20/431019.aspx 和http://aspnet.4guysfromrolla.com/articles/111605-1.aspx ,敘述得真是很不錯.)

最初的想法

這個問題最重要的就是它始終重新開始, 這就意味著可以對此做現場調試。但我們暫不走那么遠，先回頭看看現在有什么...

1. 堆棧溢出

2. 一次又一次重新開始的循環

 我已經在先前的博客帖子里討論過堆棧溢出，現在重復一下...    引起堆棧溢出的原因是, 分配了太多的函數指針，變量指針和參數，以致在堆棧里申請的內存數量不夠用。到目前為止，堆棧溢出最平常的原因是無終止的遞歸。換句話說，function A調用了function B, function B又調用了function A...

因此，callstack看上去有點像這樣....

...
functionB()
functionA()
functionB()
functionA() 

好了，一切都好極了，但那僅僅解釋了堆棧溢出。那么瘋狂的循環是怎么回事呢？
 
好...想象一下有這樣一個函數（在-->處有有一個斷點）

void MyRecursiveFunction(){
     for(int i=0; i<5; i++){
-->      MyRecursiveFunction();
     }
}

當你第一次停在斷點處，i的值應該是0,callstack看起來是這樣的...

MyRecursiveFunction()
...

現在調用MyRecrusive函數,每一次調用這個函數自己，會再一次出現 i=0（雖然我們并不真的在同一個loop里）。若調用MyRecrusive這個函數幾個來回，并用實際執行的代碼代替之，它將執行類似如下的代碼:

for(int i=0; i<5; i++){
   for(int i2=0; i2<5; i2++){
      for(int i3=0; i3<5; i3++){
         for(int i4=0; i4<5; i4++){
            for(int i5=0; i5<5; i5++){
               for(int i6=0; i6<5; i6++){
                  for(int i7=0; i7<5; i7++){
                     ...
                  }
               }
            }
         }
      }
   }
}

... 在visual studio中查看它，看起來總是運行同樣的循環，且并不改變變量i的值。暫時,你對此不會有深層次的理解，直到你真正看到堆棧調用。
假如我們看一下callstack, callstack現在看起來是這樣的...

MyRecursiveFunction()
MyRecursiveFunction()
MyRecursiveFunction()
MyRecursiveFunction()
MyRecursiveFunction()
MyRecursiveFunction()
MyRecursiveFunction()
...

因此最初想法的結論是，我們無疑地要看看某些遞歸...但在哪呢？例子中的代碼

      myRoot.ChildNodes.Add(new SiteMapNode(this, i.ToString(), i.ToString(), i.ToString()));

看起來并不是那么復雜...

在這兒最可疑的是new SiteMapNode() 和myRoot.ChildNodes.Add() ，假如我們用reflector查看一下，那么這將不再那么神秘。
 

調試問題

最后:)  少一點口舌，多來一點windbg行動...

因它易重新呈現，所以我會在我的機器上重新呈現它，我只要將windbg (File / Attach to process)附到w3wp.exe上，點擊g開始即可。然后會重新產生了這個問題，程序中止時提示我這是一個堆棧溢出（我們已經知道了）。
 
(7e4.ddc): Stack overflow - code c00000fd (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0fa4235c ebx=02beca74 ecx=02beca74 edx=02becb54 esi=02becb54 edi=02beca74
eip=686b5cb4 esp=02163000 ebp=02163004 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210246
System_Web_ni+0xf5cb4:686b5cb4 56 push esi

我們查看一下堆棧，使用 !clrstack命令看看是怎么中止的，但我們只能看到....

0:016> !clrstack
OS Thread Id: 0xddc (16)
ESP EIP 02163000 686b5cb4 System.Web.StaticSiteMapProvider.GetChildNodes(System.Web.SiteMapNode)

 ... 這對我們并沒有太大的幫助。有時當我們遇到堆棧溢出時，使用!clrstack 命令就會出現一些這樣的問題。因此我們還需要使用!dumpstack命令查看一下raw stack。

0:016> !dumpstack
OS Thread Id: 0xddc (16)
Current frame: (MethodDesc 0x68b03720 +0x4 System.Web.StaticSiteMapProvider.GetChildNodes(System.Web.SiteMapNode))
ChildEBP RetAddr Caller,Callee
02163004 686b1fc4 (MethodDesc 0x68aeff30 +0x18 System.Web.SiteMapNode.get_ChildNodes())
0216300c 0f765641 (MethodDesc 0xfa42328 +0x59 ViewSiteMapProvider.BuildSiteMap())
0216303c 686b5cdf (MethodDesc 0x68b03720 +0x2f System.Web.StaticSiteMapProvider.GetChildNodes(System.Web.SiteMapNode))
02163074 686b1fc4 (MethodDesc 0x68aeff30 +0x18 System.Web.SiteMapNode.get_ChildNodes())
0216307c 0f765641 (MethodDesc 0xfa42328 +0x59 ViewSiteMapProvider.BuildSiteMap())
021630ac 686b5cdf (MethodDesc 0x68b03720 +0x2f System.Web.StaticSiteMapProvider.GetChildNodes(System.Web.SiteMapNode))
021630e4 686b1fc4 (MethodDesc 0x68aeff30 +0x18 System.Web.SiteMapNode.get_ChildNodes())
021630ec 0f765641 (MethodDesc 0xfa42328 +0x59 ViewSiteMapProvider.BuildSiteMap())
0216311c 686b5cdf (MethodDesc 0x68b03720 +0x2f System.Web.StaticSiteMapProvider.GetChildNodes(System.Web.SiteMapNode))
02163154 686b1fc4 (MethodDesc 0x68aeff30 +0x18 System.Web.SiteMapNode.get_ChildNodes())
0216315c 0f765641 (MethodDesc 0xfa42328 +0x59 ViewSiteMapProvider.BuildSiteMap())
...

好了，這看起來問題出自ChildNodes屬性。使用該屬性時，會調用GetChildNodes 函數，這個函數會再次調用BuildSiteMap 函數，從而它又調用了ChildNodes 屬性，如此一直下去，導致了堆棧溢出。

結論

 在關于BuildSitemap的文檔中，你能找到如下段落：
 
BuildSiteMap 方法由 FindSiteMapNode、GetChildNodes和GetParentNode方法的默認實現調用。如果在派生類中重寫 BuildSiteMap 方法，請確保它僅加載一次站點地圖數據，并在后續調用中返回。
為了避免出現遞歸和堆棧溢出，最好避免調用該方法，像在BuildSiteMap例子里，我們可以用AddNode方法來添加子節點。
這在歸檔在Site Map Providers這篇文章中，該文同樣值得一讀。
BuildSiteMap 一般不應當調用其他的site map提供的方法或屬性，因為許多方法和屬性默認會實現BuildSiteMap調用。 例如，BuildSiteMap中的RootNode會引起遞歸，從而使之以堆棧溢出而終止。 
http://www.survivalescaperooms.com/Ring1981/archive/2006/10/19/443280.html