Counterfactual Debugging: Dereference Fixpoints
Forthcoming Webinar on Pattern-Driven Software Diagnostics
2012 - The Year of Software Trace Analysis
Accelerated Memory Dump Analysis Training
Sponsored link: Memory Dump Analysis Services
Debugging Experts Magazine Online
Debugging Today Daily Newspaper
Imagine we have the following arrangements in memory:
address: value
where value == address, so we have effectively:
address: address
So when we dereference the address we get the address value. If we name the dereference function as p(address) we get
p(address) = address
That gave me an idea to name after the mathematical notion of a function fixpoint (fixed point).
In C++ we can write the following code to initialize a fixpoint:
void *pc = &pc;
in assembly language:
lea eax, [pc]
mov dword ptr [pc], eax
or using local variables:
lea eax, [ebp-4]
mov dword ptr [ebp-4], eax
Dereference of a fixpoint pointer gives us the same value as its address, for example, using old style conversion:
int *pc = (int *)&pc;
if (pc == (int *)*pc) {
// TRUE
or for C++ purists:
int *pc = reinterpret_cast<int *>(&pc);
if (pc == reinterpret_cast<int *>(*pc)) {
// TRUE
In x86 assembly language we have this comparison:
mov eax,dword ptr [pc]
mov ecx,dword ptr [pc]
cmp ecx,dword ptr [eax]
or using local variables:
mov eax,dword ptr [ebp-4]
mov ecx,dword ptr [ebp-4]
cmp ecx,dword ptr [eax]
Now, having discussed fixpoints, let me ask the question to ponder over this weekend. What would this code do?
int _tmain(int argc, _TCHAR* argv[])
{
char c;
char* pc = &c;
while(1)
{
*pc = 0;
pc++;
}
return 0;
}
Would it produce stack overflow with an exception, or stack underflow with an exception or loop indefinitely? The C++ Standard answer of compiler and platform dependence is not acceptable. I plan to elaborate on this topic on Monday.
The notion of counterfactual debugging (”what if” debugging) was inspired by the so called counterfactual history.
- Dmitry Vostokov @ DumpAnalysis.org -
Sponsored link: Professional Software Debugging Services
/* Malware and Software Defects -> Victimware.org */
Copyright © 2006 - 2012. This is a non-profit research and scientific project.
_1125.png)
Citrix and Microsoft Customer Forum
Museum of Debugging and Memory Dumps
7/7/2011 - 8/8/2011 Annual Competition: Tell Your Windows Debugging Story
Crash and Hang Analysis Audit Service
CARE: Crash Analysis Report Environment
Crash Dump and Software Trace Analysis Training and Seminars
Access OpenTask Titles on Safari Books Online
DATA (Dump Analysis + Trace Analysis) Facebook group
Please join the community of memory (dump) and trace analysis engineers. This group promotes scientific methods and memory dump-based worldview.
Twitter @ DumpAnalysis You can now follow portal and blog news at DumpAnalysis on Twitter
LinkedIn Group Dr. Watson Enthusiasts All about Dr. Watson errors and more. Get news, excerpts and progress reports about the forthcoming book The Science of Dr. Watson: An Illustrated History of Debugging (ISBN 978-1906717070)
2010 (0x7DA) - The Year of Dump Analysis 2011 (0x7DB) - 2020 (0x7E4) The Debugging Decade
International Memory Analysts and Debuggers Day: 07.07 and/or 08.08 starting from The Year of Dump Analysis, 2010, 7DA
AnnouncementsComing Soon:
Fundamentals of Complete Crash and Hang Memory Dump Analysis
Management Bits: An Anthology from Reductionist Manager
Crash Dump Analysis for System Administrators and Support Engineers
New Magazines:
Debugged! MZ/PE: MagaZine for/from Practicing Engineers
New Books:
Introduction to Pattern-Driven Software Problem Solving
Memory Dump Analysis Anthology: Color Supplement for Volumes 4-5
Windows Debugging Notebook: Essential User Space WinDbg Commands
Memory Dump Analysis Anthology, Volume 5
Memory Dump Analysis Anthology, Volume 4
Memory Dump Analysis Anthology: Color Supplement for Volumes 1-3
Memory Dump Analysis Anthology, Volume 3
First Fault Software Problem Solving: A Guide for Engineers, Managers and Users
x64 Windows Debugging: Practical Foundations
Also available:
Windows Debugging: Practical Foundations
DLL List Landscape: The Art from Computer Memory Space
Dumps, Bugs and Debugging Forensics: The Adventures of Dr. Debugalov
WinDbg: A Reference Poster and Learning Cards
Memory Dump Analysis Anthology, Volume 2
Memory Dump Analysis Anthology, Volume 1
New Children's Book:
September 11th, 2009 at 5:35 pm
It will overwrite the thread stack with zeros and it will crash with access violation when reaching StackBase.
September 12th, 2009 at 12:59 am
>if (pc == (int *)*pc) {…}
Shouldn’t that be “if (&pc == (int**)pc) {…}”?
Otherwise, this comparison can _reliable_ tell what ‘pc’ is a pointer to the fixpoint, not a fixpoint itself, right?
>overflow with an exception, or stack underflow with an exception or loop indefinitely?
Our guess is what if this code will be optimized, it will almost certainly lead to underflow in all situations. But for usual non-optimized “all vars are volatile vars” fetches – this single loop definitely produces lot’s of possibilities
September 14th, 2009 at 10:54 am
Both comparisons do the same thing in the case of a fixpoint and any multiple dereferencing by definition of a fixpont:
if (&pc == (int **)*(int *)*pc)
mov eax,dword ptr [pc]mov ecx,dword ptr [eax]
lea edx,[pc]
cmp edx,dword ptr [ecx]
Originally I myself believed in underflow in all situations until I suddenly got an infinite loop. I couldn’t believe my eyes and after the investigation as a byproduct I came to the definition of a fixpoint. I plan to write more about this later today.
September 15th, 2009 at 9:19 pm
[…] discussed dereference fixpoints we come back to the quiz code and see what happens when we execute it after compilation as default […]
September 19th, 2009 at 11:28 pm
Yeah, in case of fixpoint both comparisons indeed are the same. We tried to say what extra-indirection-level comparison will return true even if ‘pc’ is not a fixpoint itself – but rather a pointer to the fixpoint.
Example:
init:
lea eax, [pcx]
mov [eax], eax ; pcx is a fixpoint now
mov [pc], eax ; ‘pc’ and ‘pcx’ have different addresses
check0:
lea eax, [pc]
mov ecx, [eax]
cmp eax, ecx
je PcIsFixpoint ; check will fail
check1:
mov eax, [pc]
mov ecx, [eax]
cmp eax, ecx
je PcIsFixpointOrPointerToFixpoint ; check will succeed
Btw,.. This blog is awesome
September 22nd, 2009 at 4:26 pm
Thanks! Dmitry
January 8th, 2010 at 9:36 am
[…] Pointers and their links are also objects and arrows to form a category, called MemP(tr). The following picture illustrates it with the last pointer shown as a dereference fixpoint: […]
August 18th, 2010 at 3:45 pm
[…] class memory layout I made sure that it points to the same heap address by making vtable pointer a dereference fixpoint. Here is a source code based on how Visual C++ compiler implements objects in […]