91 <p>Any stack entries which do not match functions, for example, those that relate to data (for example descriptors, integers etc.) are hidden.</p> |
91 <p>Any stack entries which do not match functions, for example, those that relate to data (for example descriptors, integers etc.) are hidden.</p> |
92 <p>The crash occurs at the program counter location, and then typically the previous function to be executed prior to this is contained within the link register. After this, the stack data must be used to reconstruct the crash location. Work from the current stack pointer downwards and inspect each function in question.</p> |
92 <p>The crash occurs at the program counter location, and then typically the previous function to be executed prior to this is contained within the link register. After this, the stack data must be used to reconstruct the crash location. Work from the current stack pointer downwards and inspect each function in question.</p> |
93 <p>Note that typically Crash Analyser performs a heuristic match that compares the stack data with supplied symbolic information. In some situations, the stack can contain the addresses of previous function calls that are not relevant to the current call stack. This is called “ghosting” and usually arises because an unintialised area of memory is reserved from the stack (for example, Symbian OS descriptors behave in this way). In such situations, since the stack memory is not wiped, any prior function addresses within the reserved stack area may contain references to old call chains. As such, it is important to use common sense and basic understanding of the component source code in conjunction with the call stack data in order to rule out irrelevant ghost entries.</p> |
93 <p>Note that typically Crash Analyser performs a heuristic match that compares the stack data with supplied symbolic information. In some situations, the stack can contain the addresses of previous function calls that are not relevant to the current call stack. This is called “ghosting” and usually arises because an unintialised area of memory is reserved from the stack (for example, Symbian OS descriptors behave in this way). In such situations, since the stack memory is not wiped, any prior function addresses within the reserved stack area may contain references to old call chains. As such, it is important to use common sense and basic understanding of the component source code in conjunction with the call stack data in order to rule out irrelevant ghost entries.</p> |
94 <p>It is also important to verify if the value of the current stack pointer (R13) falls within or outside of the bounds of the stack. If the value of R13 is outside, or then very close to the stack boundary, then it may indicate a stack overflow which will result in an exception, typically reported in Symbian OS as a KERN-EXEC 3 panic.</p> |
94 <p>It is also important to verify if the value of the current stack pointer (R13) falls within or outside of the bounds of the stack. If the value of R13 is outside, or then very close to the stack boundary, then it may indicate a stack overflow which will result in an exception, typically reported in Symbian OS as a KERN-EXEC 3 panic.</p> |
95 |
95 |
96 <div id="footer">Copyright © 2009 Nokia Corporation and/or its subsidiary(-ies). All rights reserved. |
96 <div id="footer">Copyright © 2010 Nokia Corporation and/or its subsidiary(-ies). All rights reserved. |
97 License: <a href="http://www.eclipse.org/legal/epl-v10.html">http://www.eclipse.org/legal/epl-v10.html</a>.</div> |
97 License: <a href="http://www.eclipse.org/legal/epl-v10.html">http://www.eclipse.org/legal/epl-v10.html</a>.</div> |
98 </body> |
98 </body> |
99 </html> |
99 </html> |