ASP. NET crash-crazy loop in sitemap)

Author: Tess
Original article address: ASP. NET crash-crazy looping in a sitemap

This article is just a quick general translation. If you are interested, please read the original version.

I want to quickly create a site map that is not beautiful, So I simply put it in my override buildsitemap () the function adds several map nodes (sitemap nodes) using a small loop)

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;
}

When I run this web applicationProgramIn this case, I got "stack overflow", and the server crashed. Then I used the debugger to debug this section.CodeWhat I see is very strange:

1 ) Int I =   0
2 ) I <   5
3 ) Myroot
4 ) Int I =   0
5 ) I <   5
Etc.

It seems that the I value has not increased. Is it a compiler bug or CLR? (Currently, the internal mechanism of sitemap is removed, because sitemap is not designed to be used in this way, but you can write this statement at will)

Before debugging, let's move back and review:

1. Stack Overflow
2. A seemingly endless loop

Stack Overflow occurs because we have occupied a large amount of memory, and they serve to allocate too many pointers to local variables or parameters on the stack. (we have exceeded the amount of memory reserved for the stack by allocating too functions pointers, pointers to local vars and parameters on the stack .) however, it is often because of the never-ending recursion. In other words, funcitona () calls functionb (), and functionb () calls functiona ().

Void Myrecursivefunction () {
For ( Int I = 0 ; I < 5 ; I ++ ) {
-->Myrecursivefunction ();
}
}  

So our call stack should look like this:

Functionb ()
Functiona ()
Functionb ()
Functiona ()

Well, now let's imagine if you have such a function:

When you stop at the breakpoint for the first time, the I value should be 0, and the call stack should look like

Myrecursivefunction ()
...

Now we can execute the function in another way (it is actually itself)

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 ++ ){

}
}
}
}
}
}
}

So the call stack should be like this:

Myrecursivefunction ()
Myrecursivefunction ()
Myrecursivefunction ()
Myrecursivefunction ()
Myrecursivefunction ()
Myrecursivefunction ()
Myrecursivefunction ()
 

Debugging:

Attach windbgto the w3wp.exe process (File/attach to the process), and press g to run the program. The program will be terminated and the following information is displayed, indicating that the stack overflows (as we already know)

(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 = 02beca74eip = 109esp = 02163000 EBP = 02163004 iopl = 0 NV up ei pl Zr na PE NCCs = 0023 SS = 002b DS = 002b es = 002b FS = 0053 GS = 002b EFL = 00210246system_web_ni + 0xf5cb4:
686b5cb4 56 push ESI
 

If we use it! Clrstack takes a look at the stack to determine how we ended. We can only see this:

 
0: 016>! Clrstackos thread ID: 0 xddc (16) ESP EIP
02163000 686b5cb4 system. Web. staticsitemapprovider. getchildnodes (system. Web. sitemapnode)
 

Unfortunately, this cannot tell us more things. When we get into a stack overflow error! Clrstack sometimes has some problems in listing stack information, so we must use it! Dumpstack.
(Note :! Dumpstack does not display real stacks. Some functions may be wrong, but it can help us to know exactly what happened)

0: 016>! Dumpstackos thread ID: 0 xddc (16) current frame: (methoddesc 0x68b03720 + 0x4 system. web. staticsitemapprovider. getchildnodes (system. web. sitemapnode) childebp retaddr caller, callee02163004 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 ())...

OK, it seems that the problem lies in the childnodes attribute. It calls the getchildnodes () function, and getchildnodes () calls our buildsitemap function again, which calls the childnodes attribute, this leads to an endless loop.

Conclusion:

You can find the answer and solution in the article "Create a site map ".ArticleThe correct solution to the problem at the beginning.