.text:10031236 mov esi, esp <----- save the ESP value in ESI to check if it's the same
after the next call
.text:10031238 push 0
.text:1003123A sub esp, 14h
.text:1003123D mov ecx, esp
.text:1003123F mov edx, [ebp-100h]
.text:10031245 mov [ecx], edx
.text:10031247 mov eax, [ebp-0FCh]
.text:1003124D mov [ecx+4], eax
.text:10031250 mov edx, [ebp-0F8h]
.text:10031256 mov [ecx+8], edx
.text:10031259 mov eax, [ebp-0F4h]
.text:1003125F mov [ecx+0Ch], eax
.text:10031262 mov edx, [ebp-0F0h]
.text:10031268 mov [ecx+10h], edx
.text:1003126B push offset aIntInitpluginS ; "int InitPlugin(string &in)"
.text:10031270 mov eax, [ebp+8]
.text:10031273 mov edx, [eax]
.text:10031275 mov ecx, [ebp+8]
.text:10031278 call dword ptr [edx+1Ch] <----- ScriptEngine->RegisterGlobalFunction(
"int InitPlugin(string &in)",
asFUNCTION(InitPlugin),
asCALL_CDECL);
.text:1003127B cmp esi, esp <----- ESP value is 0x4 bytes bigger then the value saved in ESI earlier
.text:1003127D call sub_1002D67B <----- display error if Z flag is not set (ESI!=ESP)
</code>
Basically what happens is when the last parameter is due to be pushed onto the stack, something corrupts it and places an erroneous value onto the stack. We've eliminated the problem by removing a #pragma pack(1), but do not fully understand the cause or the solution.
Error in stack frame with ESP
Author
I've been running across this problem recently, and apparently at least 1 other guy has had it in the past:
http://www.gamedev.net/community/forums/viewreply.asp?ID=1528883
It's not an angelscript problem per se, but it does affect the ability to use AS.
Here is what happens:
I believe I just answered your question by e-mail, if not then it is a huge coincidence that the question is almost identical (including comments in the disassembly). [wink]
Anyway, I'll post my answer here as well, since it may help others too.
---
Did you download a new version of AngelScript when this happened?
I don't know why you would get this error. The most likely is that you
changed the version of AngelScript and MSVC didn't detect this change
nor recompiled the code, thus your plugin is calling the wrong method
on the engine (though looking at your disassembly it seems to be
correct, with 7 dwords pushed on the stack, and the virtual method
with index 7 being called). Try recompiling the entire project (both
the library and your plugin) using the "Build->Rebuild All" command.
Another developer mentioned problem with the ESP when compiling WTL
projects. I'm not sure if this is your case, but if it is, then you
could try his solution. He fixed this by defining the preprocessor
flags WIN32, _WINDOWS, STRICT in the project settings and then
recompiling everything.
Let me know if you manage to get around this problem. I would very
much like to know the solution, so that I can help others that may
have this same problem in the future.
Regards,
Andreas
Anyway, I'll post my answer here as well, since it may help others too.
---
Did you download a new version of AngelScript when this happened?
I don't know why you would get this error. The most likely is that you
changed the version of AngelScript and MSVC didn't detect this change
nor recompiled the code, thus your plugin is calling the wrong method
on the engine (though looking at your disassembly it seems to be
correct, with 7 dwords pushed on the stack, and the virtual method
with index 7 being called). Try recompiling the entire project (both
the library and your plugin) using the "Build->Rebuild All" command.
Another developer mentioned problem with the ESP when compiling WTL
projects. I'm not sure if this is your case, but if it is, then you
could try his solution. He fixed this by defining the preprocessor
flags WIN32, _WINDOWS, STRICT in the project settings and then
recompiling everything.
Let me know if you manage to get around this problem. I would very
much like to know the solution, so that I can help others that may
have this same problem in the future.
Regards,
Andreas
Author
Quote:
I believe I just answered your question by e-mail, if not then it is a huge coincidence that the question is almost identical (including comments in the disassembly).
The person that sent you the email is developing plugins for my application. The plugins (dlls) take as their startup parameter a pointer to an instance of a script engine, then using that engine they register various classes, etc.
It's a problem we've had before but no idea really as to how to solve it. I suspect though that you are right and that the libraries are expecting two different functions due to different versions.
Ah, that would explain the similarity in your questions. You must have forwarded his to the forum, right?
Well, he seems to have discovered the problem. He was using #pragma pack(1) in his project. This probably changed the size of the asUPtr as seen by the plugin, which would explain the ESP problem. Removing the pragma solved the problem.
I'll change the AngelScript interface to take a const asUPtr& in the parameter instead. This ought to avoid some of these ESP problems in the future.
Regards,
Andreas
Well, he seems to have discovered the problem. He was using #pragma pack(1) in his project. This probably changed the size of the asUPtr as seen by the plugin, which would explain the ESP problem. Removing the pragma solved the problem.
I'll change the AngelScript interface to take a const asUPtr& in the parameter instead. This ought to avoid some of these ESP problems in the future.
Regards,
Andreas
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
