views:

137

answers:

5

How do i get the address of the variable holding an event handler?

e.g.

TExample = class(TObject)
private
    FOnChange: TNotifyEvent;
end;

i want the address of the FOnChange private member, event handler, variable.


Why?

i'm trying to figure out who is overwriting my FOnChange handler variable with junk.

i am stepping through code:

if Assigned(FOnChange) then
    FOnChange(Self);

No event handler is ever assigned, and for a while the FOnChange variable is nil in the Watch Window:

@FOnChange: nil
Addr(FOnChange): nil

But later the FOnChange variable is getting turned into junk:

@FOnChange: $2C
Addr(FOnChange): $2C

So i want to watch the FOnChange variable in data pane of the CPU window, so that i can watch it to from:

00410018 00000000

to

00410018 0000002C

Except i don't know the address of FOnChange; i just made up the $410018.

How can i find the address of an event variable?


Things i've tried

Watch List

OnChange: nil
@OnChange: nil
@@OnChange: Variable required
@FOnChange: nil
Assigned(OnChange): False
Assigned(FOnChange): False
@@FOnChange: $253B588
addr(addr(FOnChange)): $253B588

Alt+F5

  • OnChange: OnChange: TNotifyEvent $253B588
  • FOnChange: Error inspecting 'FOnChange': expression error
  • Self.FOnChange: Error inspecting 'Self.FOnChange': expression error
  • @OnChange: @OnChange: Pointer $253B588
  • @@OnChange: Error inspecting '@@OnChange': expression error
  • @FOnChange: @FOnChange: Pointer $253B588
  • @@FOnChange: @@FOnChange: ^Untyped (no address) Data: @@FOnChange $253B588`

The concensus seems to be at address 0x253B588.

Yet when i run some sample code:

MyControl1.OnChange := TheOnChangeHandler;

That turns into:

mov edx,[ebp+$08]         ;move stack variable $08 into edx
mov [eax+$00000208],edx   ;and then into offset $208 of my control

mov edx,[ebp+$0c]         ;move stack variable $0c into edx
mov [eax+$0000020c],edx   ;and then into offset $20c of my control

No wonder i can't find an address of FOnChange, it's two addresses!

+4  A: 

You can get the address through the Debug Inspector. To get the address of a field, put a breakpoint in your code at some point before the change has happened, for example right after you call the constructor. Then open your object in the Debug Inspector. Not sure how you get it in the old IDE style, but in D2010 you can get this from the Run->Inspect... menu command, from a button in Evaluate/Modify, or by hitting ALT-F5 on the keyboard. (Be careful you don't hit ALT-F4!)

The Debug Inspector will show you your object with all its fields. Double-click on one of the fields and it will open in a new Debug Inspector window. In the edit box-like bar at the top will be the address of your field. You can use this to set a memory breakpoint to find where the value changes.

Mason Wheeler
That returns `nil`; which makes sense since there is no event handler assigned.
Ian Boyd
Also returns nil in Delphi 2010
Cosmin Prund
@Ian, @Cosmin: You're right. I tested the wrong thing. Fixed it with an explanation that will actually work.
Mason Wheeler
i tried it, and tested it with Cosmin's idea of calling code to set it myself. The address i see with Alt+F5 is not altered when the `OnChange` handler is assigned to something (it stays $00000000). What address **am** i seeing, if not the variable. (i can't believe i've spent 6 hours trying to find the address of a member variable!)
Ian Boyd
You're watching X.FOnChange and it appears to stay at nil. Maybe X is the one getting overwritten, not X.FOnChange!
Cosmin Prund
@Ian: Cosmin's probably got it right here. Do the same thing, but put the breakpoint at the address of the object instead of the field.
Mason Wheeler
i'll accept this answer, even though it's not complete. i had a vague memory (from spelunking through `TThemeManager`) of a `TMethod` record, where a function is actually two pointers. Turns out that's what's happening here. Your technique does work to find the address of the start of the structure. But Delphi certainly does keep it a secret, and makes it quite difficult to hunt down.
Ian Boyd
+4  A: 

Not sure in Delphi 5 but you should be able to put a Data Breakpoint (or an Address Breakpoint) on your AExample.FOnChange.
It would break whenever the value changes.

François
You're right, that doesn't exist in Delphi 5.
Ian Boyd
Learning something everyday! That actually works as expected in Delphi 2010.
Cosmin Prund
I didn't know that either, great tip.
Alan Clark
+1 from me for actually being the best possible solution to this problem.
Cosmin Prund
+3  A: 

Since you can't use the smart solution suggested by François, it's time to get hacking! Somewhere, anywhere you can put a brakepoint, write code like this:

var X:TExample;
X.OnChange := nil;

Put a brakepoint on the X.OnChange := nil line; When the debugger stops there, take a look at the disassembly pane, you'll see something like this:

; assembler blah blah to get the address of X
xor EDX ; or whatever the compiler finds appropriate this time of day
mov [eax + $00000288], edx
mov [eax + $0000028c], edx

You don't care about the registers used by the compiler, you care about the $288, the offset used for the first MOV instruction. That's the OFFSET from the "X" address to the FOnChange field. Note it down. Now go back to your buggy program, set a brakepoint somewhere, hit Alt+F5 to invoke the Debug Inspector (followed by Ctrl+N if you're not presented with an empty edit box to type your query in) and write "Integer(MyExampleVariable)"; Whatever you get, add up the number you noted down at the previous step and you've got the address of the FOnChange filed for the MyExampleVariable instance, you can now set a address brakepoint.

Cosmin Prund
+1 for "that's ingenious". Of course i'd rather not do it, but i'd never considered that before!
Ian Boyd
+1  A: 

I don't know if they exists in Delphi 5, but the type TMethod and the function MethodAddress should be helpful.

splash
This was the missing link that i discovered. i couldn't find any documentation on TMethod (even the link you provided doesn't document it). But that's the reason an event handler is 8-bytes long.
Ian Boyd
A: 

Why?

i'm trying to figure out who is overwriting my FOnChange handler variable with junk.

I can answer that bit - you are! Or you are looking at the wrong instance that is not created correctly? not referenced correctly? It will be something like that. The Delphi debugger is good at making some thing that does not exist look like it does, until...

Step back a bit, try and see the wood not the trees. I have been where you are many times, you are probably barking up the wrong tree (sorry pun intended) and shortly will call yourself all sorts of names :)

Despatcher
Well i know it's me; of course it's me! When i say *who* i mean which line of code. Each line of source code is alive, it's conscious, and it's trying to screw me!
Ian Boyd
In the end i found the answer: the `FOnChanged` variable of my object wasn't being modified: my "self" was being modified. The object's `Self` reference, which happened to be stored in `EBX`, was being mangled on return of a function call. Turned out there was a mismatch between the caller and callee about how many variables were on the stack, and when `EBX` was popped, it was popping a junk value. Suddenly `FOnChanged` made no sense because my object's *"start address"* was junk. In reality, it was the compiler's housekeeping code that was screwing me over.
Ian Boyd
i was the one who put the *Dry Clean Only* jacket in the washing machine. i can't really fault the washing machine for ruining it. But in the end the washing machine *did* ruin it. :)
Ian Boyd
:) There you go... essentially a bad reference which the debugger made LOOK real until... Not sure the washing machine analogy washes, but it was certainly your fault! Glad you found it.
Despatcher