What's wrong with this code, Part 21 - A psychic debugging example: The missing piece

re: What's wrong with this code, Part 21 - A psychic debugging example: The missing piece

Adam — Tue, 25 Sep 2007 20:18:35 GMT

The ret 0Ch moves the stack pointer 12 bytes to clear up the args. The function only takes 8 bytes of parameters (the this pointer gets passed in ecx). I believe that means there's a parameter mismatch.

As for how it compiled I can only assume that there's two versions of the IPsychicInterface - one that is being compiled with and another that is being linked with.

re: What's wrong with this code, Part 21 - A psychic debugging example: The missing piece

Skywing — Tue, 25 Sep 2007 20:28:35 GMT

If it's within the same program, I would say that two source files had different compiler settings. The compiler wouldn't catch the call at compile time if it's a virtual function call as that doesn't require a linker lookup against the decorated symbol name (which would be wrong if the calling convention was mismatched across two files).

Another possibility is that one source file was compiled with different padding or class layout options than another source file.

Being in the same problem, it would seem to be that it's a violation of the one definition rule...

re: What's wrong with this code, Part 21 - A psychic debugging example: The missing piece

Skywing — Tue, 25 Sep 2007 20:30:46 GMT

Wow, that last sentence did not come out right at all :)

"Being in the same program, it would seem to me that it's a violation of the one definition rule..."

re: What's wrong with this code, Part 21 - A psychic debugging example: The missing piece

Stuart Ballard — Tue, 25 Sep 2007 21:00:12 GMT

Larry, have you answered the question of whether the interface, the class implementing the interface, and the application using the interface were all compiled together yet?

I can't say I actually understand the problem (and the assembly snippet made it more opaque rather than less to me) but it seems like if the interface were compiled twice, once with one calling convention and once with the other, and then the application and the implementing class were compiled against those different copies, it might cause this kind of problem?

re: What's wrong with this code, Part 21 - A psychic debugging example: The missing piece

LarryOsterman — Tue, 25 Sep 2007 21:07:35 GMT

Darn it all, Skywing. I was planning on being really geeky and mentioning the ODR and you went ahead and spoiled it for me :).

Nice job.

re: What's wrong with this code, Part 21 - A psychic debugging example: The missing piece

Tim Smith — Tue, 25 Sep 2007 21:20:46 GMT

LOL...

I was looking for really technically obscure reasons and missed the obvious one of someone doing something REALLLLLY dumb. I hope it really wasn't the case of the interface being cut/copied/pasted to two different locations.

In a big and complex code base, I could see someone having this problem similar to the issues you see when two modules use different settings for such things as WINVER.

Two definitions, different vtable ordering, the wrong routine getting called.

re: What's wrong with this code, Part 21 - A psychic debugging example: The missing piece

barrybo — Tue, 25 Sep 2007 21:43:23 GMT

"thiscall" strikes again!

re: What's wrong with this code, Part 21 - A psychic debugging example: The missing piece

Tim Smith — Tue, 25 Sep 2007 22:02:20 GMT

Barry: How is this an issue with thiscall?

re: What's wrong with this code, Part 21 - A psychic debugging example: The missing piece

Justin Rudd — Tue, 25 Sep 2007 23:25:45 GMT

Since the type of parameter is _TCHAR, my guess is that one or the other compilation units was compiled with _UNICODE defined. The compilation unit that had it defined saw _TCHAR == wchar_t and the one that didn't saw _TCHAR == char.

Originally I didn't see how that would cause a stack problem because it is an array of pointers which is still 4 bytes no matter wchar_t or char.

The only thing I can think of is if DoSomeOperation used the ATL character conversion functions, those use stack space. And those would think that the pointer coming in contained the wrong character set and that might stomp on the stack a bit.

re: What's wrong with this code, Part 21 - A psychic debugging example: The missing piece

anon — Wed, 26 Sep 2007 01:15:27 GMT

I am not quite sure if this is what skywing was getting at, but I was trying to see if it was possible to define an overload of the DoSomeOperation method that would take 3 or more parameters, with the 3rd taking a default value. In which case, the compiler might not complain about the call in the code above (viz default value assigned), but such an overload does not satisfy the implementation for the virtual DoSomeOperation method (you're left with an abstract class)...

So I am not sure. Sorry for rambling.

re: What's wrong with this code, Part 21 - A psychic debugging example: The missing piece

B.Y. — Wed, 26 Sep 2007 01:56:13 GMT

From the disassembly, it's obvious DoSomeOperation() is using a calling convention where the callee cleans up the stack.

Let assume _tmain is using the default C calling convention, where the caller cleans up the stack. The fact that the program run means it linked OK, so that means GetPsychicInterface() most likely got the interface from a DLL or something, where the interface was compiled and linked using a non-C calling convention.

re: What's wrong with this code, Part 21 - A psychic debugging example: The missing piece

Charlie — Wed, 26 Sep 2007 03:03:34 GMT

Was the IPsychicInterface object implemented in C (rather than C++)? This is possible (although a little unorthodox these days). If so, then the implementation of DoSomeOperation() is likely using the wrong calling convention.

re: What's wrong with this code, Part 21 - A psychic debugging example: The missing piece

LarryOsterman — Wed, 26 Sep 2007 03:15:02 GMT

Charlie, nope. Skywing nailed it the first post: it was a violation of the one definition rule.

re: What's wrong with this code, Part 21 - A psychic debugging example: The missing piece

JCAB — Wed, 26 Sep 2007 03:34:42 GMT

Nitpick:

"the last bit of assembly language" indicates that there will be a stack imbalance _after_ returning from DoSomeOperation. That wouldn't show as a trashed ESI upon returning from DoSomeOperation.

There must be some other imbalance (ODR violation or otherwise) inside of DoSomeOperation.

"the last bit of assembly language" does indicate that there is ODR violation in the program, so it's likely that the other imbalance will also be caused by ODR in some other function called from inside of DoSomeOperation, but not certain.

re: What's wrong with this code, Part 21 - A psychic debugging example: The missing piece

Amit — Wed, 26 Sep 2007 20:06:39 GMT

I think this is a mismatch between stdcall and thiscall.

The function is implemented as stdcall and the caller is assuming the thiscall.

If for the for implementer the calling convention is defined (in some header file) as stdcall and for the user it is defined as thiscall (in a different header file or as a compiler setting) it will keep the compiler happy.

re: What's wrong with this code, Part 21 - A psychic debugging example: The missing piece

LarryOsterman — Wed, 26 Sep 2007 20:11:37 GMT

A mismatch between stdcall and fastcall would have presented differently - the stack would be unbalanced low, not high, and the function would likely have crashed because it's parameters weren't enregistered as expected.

What's wrong with this code, part 21 - A Psychic Debugging Example - The answers.

Larry Osterman's WebLog — Wed, 26 Sep 2007 23:17:33 GMT

So for the past couple of posts , I've been walking through a psychic debugging experience I had over

What's wrong with this code, part 21 - A Psychic Debugging Example - The answers.

Noticias externas — Wed, 26 Sep 2007 23:27:36 GMT

So for the past couple of posts , I've been walking through a psychic debugging experience I had