gamedevlists-windows

[GD-Windows] Strange prolog function issue

[Emmanuel A. <e_a...@ya...>]

Hi all, 
 
 
I have here a very strange issue.
 
We have a function using a local std::string, exceptions, and a alloca.
 
When the exception is thrown, the unwind mecanism tries to delete the std::string, but it deletes it at a wrong address( there is a 0x590 offset ).
 
We debugged this problem for two days, and it only happens when the alloca is present.
In this case, the prolog of the function is of this type :
 
00F60F00  push        ebp  
00F60F01  lea         ebp,[esp-590h]                 ***** NOTICE THE STRANGE EBP VALUE HERE
00F60F08  push        0FFFFFFFFh 
00F60F0A  push        offset __ehhandler$?CompileOneVariableDeclaration@AIE_cl_Compiler@@AAEXXZ (139B888h) 
00F60F0F  mov         eax,dword ptr fs:[00000000h] 
00F60F15  push        eax  
00F60F16  mov         dword ptr fs:[0],esp 
00F60F1D  sub         esp,5ECh 
00F60F23  mov         eax,dword ptr [___security_cookie (16A1EECh)] 
00F60F28  push        ebx  
00F60F29  push        esi  
00F60F2A  mov         dword ptr [ebp+580h],eax 
00F60F30  push        edi  
00F60F31  mov         ebx,ecx 
 
 
As without the alloca, the prolog is like :
00402580  push        ebp  
00402581  mov         ebp,esp            *********** HERE, AS ALWAYS, EBP IS SET TO ESP
00402583  push        0FFFFFFFFh 
00402585  push        offset __ehhandler$?MyFunc@@YAXXZ (420738h) 
0040258A  mov         eax,dword ptr fs:[00000000h] 
00402590  push        eax  
00402591  mov         dword ptr fs:[0],esp 
00402598  sub         esp,34h 
0040259B  mov         eax,dword ptr [___security_cookie (429608h)] 
004025A0  push        ebx  
004025A1  push        esi  
004025A2  mov         dword ptr [ebp-10h],eax 
004025A5  push        edi  
 
Note that in our crashing case, ebp is set to esp - 590 ( the offset value ), and that in the other case, it is just set to esp.
 
 
I could not reproduce this ebp offset that makes the exception handler fail in a small sample. 
So do you know in which case the compiler does not put esp in ebp, but put an offset in it ?
And do you know how to fix it ( other than what we're doing : stopping using alloca with exceptions ), if it is a kind a known issue ?
 
 
Thanks for any help, 
 
Emmanuel

Re: [GD-Windows] Strange prolog function issue

[Jamie F. <ja...@qu...>]

Emmanuel Astier wrote:
> So do you know in which case the compiler does not put esp in ebp, but put an offset in it ?
> And do you know how to fix it ( other than what we're doing : stopping using alloca with exceptions ), if it is a kind a known issue ?

Last time I saw anything like that on Windows was (IIRC) when we were 
switching from VC 7.0 to 7.1 (might have been 6.0 to 7.0). If we had a 
mixed build (i.e. libs built with one version, app with another), you'd 
get strange things happening at the interfaces, where the compilers just 
wouldn't agree with each other as to what they should be doing.

May well not be your problem, though.

Jamie

[GD-Windows] Re : Strange prolog function issue

[Emmanuel A. <e_a...@ya...>]

Hi,=20
=20
Thanks for your answer, but this is not the case.
It came after a rebuild of all our project, with all our libs...
=20
As a side note, we're using VC7.1, but as we have the latest Xenon XDK, I t=
hink the compiler is vc 2005.
=20
=20
Emmanuel
=20
=20
=20


----- Message d'origine ----
De : Jamie Fowlston <ja...@qu...>
=C3=80 : Game Development for MS Windows <gam...@li...urce=
forge.net>
Envoy=C3=A9 le : Mardi, 25 Juillet 2006, 1h20mn 11s
Objet : Re: [GD-Windows] Strange prolog function issue


Emmanuel Astier wrote:
> So do you know in which case the compiler does not put esp in ebp, but pu=
t an offset in it ?
> And do you know how to fix it ( other than what we're doing : stopping us=
ing alloca with exceptions ), if it is a kind a known issue ?

Last time I saw anything like that on Windows was (IIRC) when we were=20
switching from VC 7.0 to 7.1 (might have been 6.0 to 7.0). If we had a=20
mixed build (i.e. libs built with one version, app with another), you'd=20
get strange things happening at the interfaces, where the compilers just=20
wouldn't agree with each other as to what they should be doing.

May well not be your problem, though.

Jamie

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share you=
r
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDE=
VDEV
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D555

Re: [GD-Windows] Strange prolog function issue

[Kent Q. <ken...@co...>]

Emmanuel Astier wrote:
> Hi all, 
>  
>  
> I have here a very strange issue.
>  
> We have a function using a local std::string, exceptions, and a alloca.
>  
> When the exception is thrown, the unwind mecanism tries to delete the std::string, but it deletes it at a wrong address( there is a 0x590 offset ).
>  
> <snip> 
>  
> I could not reproduce this ebp offset that makes the exception handler fail in a small sample. 
> So do you know in which case the compiler does not put esp in ebp, but put an offset in it ?
> And do you know how to fix it ( other than what we're doing : stopping using alloca with exceptions ), if it is a kind a known issue ? 
>   

Does the bug occur in both debug and release builds? Have you tried 
setting the optimization manually for that file?  In any large project, 
I usually find a couple of files that drive some form of compiler bug 
under full optimization, and I have to manually turn down the 
optimization on that particular file or do some sort of special (heavily 
commented!) adaptation, such as moving a function's location in the 
source file, or in the header file. You might also try playing with a 
couple of exception-related compiler switches. Compilers are complicated 
beasts, and any project of a significant size is likely to drive a bug 
or two.

[GD-Windows] Re : Strange prolog function issue

[Emmanuel A. <e_a...@ya...>]

Hi,=20
=20
It only happens in release build. And as you said, I suspect a compiler bug=
.
=20
Actually, I don't understand when the compiler decide to switch to a differ=
ent prolog for the function, where ebp doesn't have the same meaning.
It is all fine as the function code knows the different ebp meaning, and ha=
s no trouble accessing local vars, but the exception handler seems not to b=
e aware of the change in the ebp meaning.
=20
Thanks for your help,=20
we send a mail to microsoft, we will wait for their anwser...
=20
Emmanuel

Ps : Kent, replying to your mails only replies to you, not to the list...=
=20

----- Message d'origine ----
De : Kent Quirk <ken...@co...>
=C3=80 : Emmanuel Astier <e_a...@ya...>; Game Development for MS Windo=
ws <gam...@li...>
Envoy=C3=A9 le : Mardi, 25 Juillet 2006, 6h09mn 40s
Objet : Re: [GD-Windows] Strange prolog function issue


Emmanuel Astier wrote:
> Hi all,=20
> =20
> =20
> I have here a very strange issue.
> =20
> We have a function using a local std::string, exceptions, and a alloca.
> =20
> When the exception is thrown, the unwind mecanism tries to delete the std=
::string, but it deletes it at a wrong address( there is a 0x590 offset ).
> =20
> <snip>=20
> =20
> I could not reproduce this ebp offset that makes the exception handler fa=
il in a small sample.=20
> So do you know in which case the compiler does not put esp in ebp, but pu=
t an offset in it ?
> And do you know how to fix it ( other than what we're doing : stopping us=
ing alloca with exceptions ), if it is a kind a known issue ?=20
>  =20

Does the bug occur in both debug and release builds? Have you tried=20
setting the optimization manually for that file?  In any large project,=20
I usually find a couple of files that drive some form of compiler bug=20
under full optimization, and I have to manually turn down the=20
optimization on that particular file or do some sort of special (heavily=20
commented!) adaptation, such as moving a function's location in the=20
source file, or in the header file. You might also try playing with a=20
couple of exception-related compiler switches. Compilers are complicated=20
beasts, and any project of a significant size is likely to drive a bug=20
or two.

Re: [GD-Windows] Re : Strange prolog function issue

[deldav <del...@fr...>]

alloca allocates its memory from the stack and that space is =
automatically freed when the function returns.
That's why the compiler mess with esp and ebp ... 590h should be the =
size of your alloca (perhaps rounded to keep stack alignement)

Beware (from msdn):
	In Windows XP, if _alloca is called inside a try/catch block, you must =
call _resetstkoflw in the catch block=20

Hope that helps.

-----Message d'origine-----
De : gam...@li... =
[mailto:gam...@li...] De la part =
de
Emmanuel Astier
Envoy=E9 : mercredi 26 juillet 2006 01:13
=C0 : Game Development for MS Windows
Objet : [GD-Windows] Re : Strange prolog function issue

Hi,=20
=20
It only happens in release build. And as you said, I suspect a compiler =
bug.
=20
Actually, I don't understand when the compiler decide to switch to a =
different prolog for the function, where ebp doesn't have the
same meaning.
It is all fine as the function code knows the different ebp meaning, and =
has no trouble accessing local vars, but the exception
handler seems not to be aware of the change in the ebp meaning.
=20
Thanks for your help,
we send a mail to microsoft, we will wait for their anwser...
=20
Emmanuel

Ps : Kent, replying to your mails only replies to you, not to the =
list...=20

----- Message d'origine ----
De : Kent Quirk <ken...@co...> =C0 : Emmanuel Astier =
<e_a...@ya...>; Game Development for MS Windows
<gam...@li...>
Envoy=E9 le : Mardi, 25 Juillet 2006, 6h09mn 40s Objet : Re: =
[GD-Windows] Strange prolog function issue


Emmanuel Astier wrote:
> Hi all,
> =20
> =20
> I have here a very strange issue.
> =20
> We have a function using a local std::string, exceptions, and a =
alloca.
> =20
> When the exception is thrown, the unwind mecanism tries to delete the =
std::string, but it deletes it at a wrong address( there is
a 0x590 offset ).
> =20
> <snip>
> =20
> I could not reproduce this ebp offset that makes the exception handler =
fail in a small sample.=20
> So do you know in which case the compiler does not put esp in ebp, but =
put an offset in it ?
> And do you know how to fix it ( other than what we're doing : stopping =
using alloca with exceptions ), if it is a kind a known
issue ?=20
>  =20

Does the bug occur in both debug and release builds? Have you tried =
setting the optimization manually for that file?  In any large
project, I usually find a couple of files that drive some form of =
compiler bug under full optimization, and I have to manually turn
down the optimization on that particular file or do some sort of special =
(heavily
commented!) adaptation, such as moving a function's location in the =
source file, or in the header file. You might also try playing
with a couple of exception-related compiler switches. Compilers are =
complicated beasts, and any project of a significant size is
likely to drive a bug or two.

-------------------------------------------------------------------------=

Take Surveys. Earn Cash. Influence the Future of IT Join =
SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D555

[GD-Windows] Re : Re : Strange prolog function issue

[Emmanuel A. <e_a...@ya...>]

Hi,
=20
590 is not he size of the alloca.
This size is not known at compile time ( if it were, a mere array would be =
better ).
And actually, the alloca is not even called.
=20
As for the _resetstkoflw, we did it, but it only must be used when dealing =
with stack overflow issues, and we don't have any...
=20
But thanks for your answer anyway...
=20
=20
Emmanuel

----- Message d'origine ----
De : deldav <del...@fr...>
=C3=80 : Emmanuel Astier <e_a...@ya...>; Game Development for MS Windo=
ws <gam...@li...>
Envoy=C3=A9 le : Jeudi, 27 Juillet 2006, 3h10mn 08s
Objet : Re: [GD-Windows] Re : Strange prolog function issue


alloca allocates its memory from the stack and that space is automatically =
freed when the function returns.
That's why the compiler mess with esp and ebp ... 590h should be the size o=
f your alloca (perhaps rounded to keep stack alignement)

Beware (from msdn):
    In Windows XP, if _alloca is called inside a try/catch block, you must =
call _resetstkoflw in the catch block=20

Hope that helps.

-----Message d'origine-----
De : gam...@li... [mailto:gamedevlist=
s-w...@li...] De la part de
Emmanuel Astier
Envoy=C3=A9 : mercredi 26 juillet 2006 01:13
=C3=80 : Game Development for MS Windows
Objet : [GD-Windows] Re : Strange prolog function issue

Hi,=20

It only happens in release build. And as you said, I suspect a compiler bug=
.

Actually, I don't understand when the compiler decide to switch to a differ=
ent prolog for the function, where ebp doesn't have the
same meaning.
It is all fine as the function code knows the different ebp meaning, and ha=
s no trouble accessing local vars, but the exception
handler seems not to be aware of the change in the ebp meaning.

Thanks for your help,
we send a mail to microsoft, we will wait for their anwser...

Emmanuel

Ps : Kent, replying to your mails only replies to you, not to the list...=
=20

----- Message d'origine ----
De : Kent Quirk <ken...@co...> =C3=80 : Emmanuel Astier <e_astie=
r...@ya...>; Game Development for MS Windows
<gam...@li...>
Envoy=C3=A9 le : Mardi, 25 Juillet 2006, 6h09mn 40s Objet : Re: [GD-Windows=
] Strange prolog function issue


Emmanuel Astier wrote:
> Hi all,
> =20
> =20
> I have here a very strange issue.
> =20
> We have a function using a local std::string, exceptions, and a alloca.
> =20
> When the exception is thrown, the unwind mecanism tries to delete the std=
::string, but it deletes it at a wrong address( there is
a 0x590 offset ).
> =20
> <snip>
> =20
> I could not reproduce this ebp offset that makes the exception handler fa=
il in a small sample.=20
> So do you know in which case the compiler does not put esp in ebp, but pu=
t an offset in it ?
> And do you know how to fix it ( other than what we're doing : stopping us=
ing alloca with exceptions ), if it is a kind a known
issue ?=20
>  =20

Does the bug occur in both debug and release builds? Have you tried setting=
 the optimization manually for that file?  In any large
project, I usually find a couple of files that drive some form of compiler =
bug under full optimization, and I have to manually turn
down the optimization on that particular file or do some sort of special (h=
eavily
commented!) adaptation, such as moving a function's location in the source =
file, or in the header file. You might also try playing
with a couple of exception-related compiler switches. Compilers are complic=
ated beasts, and any project of a significant size is
likely to drive a bug or two.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's =
Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDE=
VDEV
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D555


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share you=
r
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDE=
VDEV
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D555