Subj : Re: BC++ 5.02 Stack Restore Bug
To   : borland.public.cpp.borlandcpp
From : Ed Mulroy [TeamB]
Date : Tue Nov 30 2004 10:30 pm

It's just a guess but look at the options settings.  One of the options is
to
use a standard stack frame.  Check if it is disabled.

Note: if you change an option setting, then do a Project|Build instead of a
Project|Make to force the changes to be reflected in all the object files.

However, looking at the TSCOR20CaptureThread::IncrCaptureOk function in that
assembly listing, I do not see why 'mov esp,ebp' would be required.  The
stack pointer is never altered to provide automatic storage and the the
value of esp at the end is correct for doing the pop or the two pushed
register values.

With C++ calling conventions, each function is responsible for preserving
the value in esp.  I see a call to flycaptureUnlock.  You might want to look
at the register values before and after that call.

That the code does not clean up the space on the stack for the calling
arguments after the return implies that flycaptureUnlock is a __stdcall
(WINAPI) function, the type that cleans up the space on the stack itself
with a command such as
    RET 6.
Try looking at what it actually does.

..  Ed

>kurt jensen wrote in message
> news:41AD052D.357F9A3A@SPAMspiricon.com...
>
> for some perverse reason my Borland C++ 5.02 compiler has
> decided to pull funny tricks on me.  after spending a week
> blaming the DLL vendor I stumbled onto a "situation" in the
> assembly representation of my compiled code.
>
> everything looks fine until you get to the "ret" statement - then
> we ALWAYS return to address 0x00000000.  the reason is that
> the compiler left out one very important statement, "mov esp,ebp",
> i.e.  the stack pointer is NEVER restored before popping ebp and
> 'ret'urning from the function call.  because of that, we always try to
> return to the wrong address which is always 0 because of a
> parameter in a function call.
>
> anybody seen this particular problem before???  anybody have any
> idea what would possess the compiler to pull such a stunt???  and,
> more  importantly, how can I convince it to properly restore the
> stack before returning???
>
> TIA,
>
> Kurt
>
>
> below is the "C++ to Assembler" representation of the problem.  notice
> at the end after label @156, we properly pop ebx, "mov esp,ebp" is
> missing, pop ebp, and 'ret'urn.
>
>
> @TSCOR20CaptureThread@IncrCaptureOk$qi proc near
> ?live1@3616:
>    ;
>    ; bool TSCOR20CaptureThread::IncrCaptureOk(int buffer)
>    ;
> ?debug L 779
> push      ebp
> mov       ebp,esp
> push      ebx
> mov       eax,dword ptr [ebp+12]
> mov       ebx,dword ptr [ebp+8]
>    ;
>    ; {
>    ; FlyCaptureError CameraError;
>    ;
>    ; if (buffer > 0)
>    ;
> ?debug L 783
> ?live1@3632: ; EBX = this, EAX = buffer
> @152:
> test      eax,eax
> jle       short @153
>    ;
>    ; {
>    ; CameraError = flycaptureUnlock(FCameraContext, buffer-1);
>    ;
> ?debug L 785
> dec       eax
> push      eax
> push      dword ptr [ebx+22]
> call      flycaptureUnlock
>    ;
>    ; if (CameraError == FLYCAPTURE_OK)
>    ;
> ?debug L 786
> ?live1@3664: ; EBX = this, EAX = CameraError
> test      eax,eax
> jne       short @155
>    ;
>    ; CaptureOK++;
>    ;
> ?debug L 787
> ?live1@3680: ; EBX = this
> inc       dword ptr [ebx+30]
>    ;
>    ; } // then, started
>    ;
> ?debug L 788
> ?live1@3696: ;
> jmp       short @155
>    ;
>    ; else
>    ; {
>    ; CaptureOK++;
>    ;
> ?debug L 791
> ?live1@3712: ; EBX = this
> @153:
> inc       dword ptr [ebx+30]
>    ;
>    ; } // else
>    ;
>    ; return true;
>    ;
> ?debug L 794
> ?live1@3728: ;
> @155:
> mov       al,1
>    ;
>    ; } // TSCOR20CaptureThread::IncrCaptureOk()
>    ;
> ?debug L 795
> @157:
> @156:
> pop       ebx
> pop       ebp
> ret
> ?debug L 0
> @TSCOR20CaptureThread@IncrCaptureOk$qi endp

.