Re: vs 8 bug ?
One of your functions have calling conventions mismatch. Call them through a
real "proxy" function. If there is calling convention mismatch, in the debug
build you'll get an assert immediately.
"gordon" <gordon@discussions.microsoft.com> wrote in message
news:D3912303-297D-4BF0-84A7-84842795B3DB@microsoft.com...
thanks for your interest, Ben. I will try to provide the info you ask for
...
---------- a little more of calling code -----------
while(nApuUpdateStatus!=ATS_ALLSYSMODETESTS_COMPLETE)
0040124D 83 7D F8 29 cmp dword ptr [ebp-8],29h
00401251 0F 84 9D 00 00 00 je main+224h (4012F4h)
{
fCurrentSimulationTime+=dT;
00401257 DD 45 A8 fld qword ptr [ebp-58h]
0040125A DC 45 D0 fadd qword ptr [ebp-30h]
0040125D DD 5D A8 fstp qword ptr [ebp-58h]
x=fCurrentSimulationTime;
00401260 DD 45 A8 fld qword ptr [ebp-58h]
00401263 DD 5D E0 fstp qword ptr [ebp-20h]
pApuUpdateHWclock(fCurrentSimulationTime);
00401266 83 EC 08 sub esp,8
00401269 DD 45 A8 fld qword ptr [ebp-58h]
0040126C DD 1C 24 fstp qword ptr [esp]
0040126F FF 15 E8 C4 47 00 call dword ptr [_pApuUpdateHWclock
(47C4E8h)]
00401275 83 C4 08 add esp,8
__asm nop
00401278 90 nop
_pApuFubar(x);
00401279 83 EC 08 sub esp,8
0040127C DD 45 E0 fld qword ptr [ebp-20h]
0040127F DD 1C 24 fstp qword ptr [esp]
00401282 FF 55 A4 call dword ptr [ebp-5Ch]
nApuUpdateStatus=pApuUpdateRunUtil(dT);
00401285 DD 45 D0 fld qword ptr [ebp-30h]
00401288 DD 1C 24 fstp qword ptr [esp]
0040128B FF 55 C8 call dword ptr [ebp-38h]
0040128E 83 C4 08 add esp,8
00401291 89 45 F8 mov dword ptr [ebp-8],eax
pApuInterfaceOut(dT,
y0_LabData,
y1_shadow_out,
y2_msg6d1,
y3_msg6d2,
y4_msg6d3,
y5_msg350,
y6_msg360,
.
.
.
----------- and the extern declaration -----------
// declared in the dll header which is inlcuded
// in the calling module ...
__declspec( dllexport ) void APU_UpdateHWclock(double
fCurrentSimulationTime);
. . . .
// declared in the calling module
typedef void (__cdecl *APU_UPDATE_HWCLOCK_FUNC)(double dT);
APU_UPDATE_HWCLOCK_FUNC pApuUpdateHWclock ;
------------------------------------------------------
there is some "bug" someplace, because when placed inside a loop there is
eventually a stack overflow fault reported by the environment ...
i thought it might be some sort of optimization too, but then I added the
nop to alter the instruction stream, just to see what might happen ...
further, wouldn't the "optimization" still produce the same "efficiency"
regardless of whether a nop is present or not ?
certainly the stack pointer should always be at the same value before the
next call at any given level is made ... this HAS to be true ...
and, yet, without the nop, the stack just creeps downward until the the
1meg
default boundary is crossed ... of course this results in a crash ...
gordon