Re: Re : Strange prolog function issue
"deldav" <[email protected]> Thu, 27 Jul 2006 15:10:08 +0200
| Newsgroups | gmane.games.devel.windows |
|---|---|
| Message-ID | <[email protected]> |
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 Hope that helps. -----Message d'origine----- De : [email protected] [mailto:[email protected]] De la part de Emmanuel Astier Envoyé : mercredi 26 juillet 2006 01:13 À : Game Development for MS Windows Objet : [GD-Windows] Re : Strange prolog function issue Hi, 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 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. 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... ----- Message d'origine ---- De : Kent Quirk <[email protected]> À : Emmanuel Astier <[email protected]>; Game Development for MS Windows <[email protected]> Envoyé le : Mardi, 25 Juillet 2006, 6h09mn 40s Objet : Re: [GD-Windows] Strange prolog function issue 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. ------------------------------------------------------------------------- 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=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Gamedevlists-windows mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=555 ------------------------------------------------------------------------- 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=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Gamedevlists-windows mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=555