void Init()
{
int state = 0;
DoFunction1();
state = 1;
DoFunction2();
state = 2;
DoFunction3();
state = 3;
DoFunction4();
state = 4;
}
void Update()
{
Debug.Trace(state);
}
🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Code not finishing execution?
Author
I've had angelscript working for a while now, but during some tests I've noticed that code does not seem to execute consistently.
I have code that looks like this:
My engine calls Init() during the first game logic tick, and calls Update() every game logic tick. Debug.Trace() lets me inspect the value of a variable.
State will be 2 instead of 4. If I make a few seemingly meaningless changes, recompile the script, change the code back again, and run the test again, State will be 4. Any ideas why Angelscript is not finishing execution?
Note that some of the functions are overloaded, though I don't think this makes a difference.
Thanks
Is DoFunction3() and DoFunction4() called? Maybe DoFunction3() raises some exception or suspends the the script somehow so that it doesn't complete the execution.
What is the return code for Execute() when you call the Init() script function? It should be 0 (asEXECUTION_FINISHED) if the script completed the entire script.
What is the return code for Execute() when you call the Init() script function? It should be 0 (asEXECUTION_FINISHED) if the script completed the entire script.
Author
Oops, I forgot to mention that all 4 functions are C++ functions exposed to angelscript that don't do too much. It enters the first one or two, but then never gets to the others.
One thing of interest is that the first few calls are to functions called "void PersistVariable(string &name, <typename> value)." If I remove these calls, the code manages to finish. They take the name of the variable and it's value as parameters. They are overloaded based on type (int, float, bool, and string&). The type is used only to get the size (or string length for strings).
The function called from angelscript is a wrapper function that merely calls the "real" functions, which are "void PersistVariable(const char* name, void* value, int size)" and "void PersistString(const char* name, const char* value)" These functions merely search for the variable by name in a list. If they do not find it, they allocate a class that stores the name, value, and size of the varible using newly allocated memory. If they do find it (the variable already exists), they reallocate space and then update the value stored.
The idea is that the script can make a single persist call which will maintain a variable's in C++ memory, even after releasing and recreating my contexts/modules several times. And the ability to store variable names and values works for saving user progress :)
I'll have to check the return value of the execute call when I have access to the code next week. Although I'm not sure how angelscript could be going into my C++ code and never returning from it.
One thing of interest is that the first few calls are to functions called "void PersistVariable(string &name, <typename> value)." If I remove these calls, the code manages to finish. They take the name of the variable and it's value as parameters. They are overloaded based on type (int, float, bool, and string&). The type is used only to get the size (or string length for strings).
The function called from angelscript is a wrapper function that merely calls the "real" functions, which are "void PersistVariable(const char* name, void* value, int size)" and "void PersistString(const char* name, const char* value)" These functions merely search for the variable by name in a list. If they do not find it, they allocate a class that stores the name, value, and size of the varible using newly allocated memory. If they do find it (the variable already exists), they reallocate space and then update the value stored.
The idea is that the script can make a single persist call which will maintain a variable's in C++ memory, even after releasing and recreating my contexts/modules several times. And the ability to store variable names and values works for saving user progress :)
I'll have to check the return value of the execute call when I have access to the code next week. Although I'm not sure how angelscript could be going into my C++ code and never returning from it.
I'm guessing you're actually receiving a return code of asEXECUTION_EXCEPTION (= 3). And if you call the functions GetExceptionLineNumber(), GetExceptionFunction(), GetExceptionString(), you should be able to figure out what's going on.
You may even use SetExceptionCallback() which would allow you to examine the values on the script stack at the moment of the exception.
Let me know if that is not it, so that we can work together and find the true problem.
Regards,
Andreas
You may even use SetExceptionCallback() which would allow you to examine the values on the script stack at the moment of the exception.
Let me know if that is not it, so that we can work together and find the true problem.
Regards,
Andreas
Author
Ok, a few updates.
The error does not occur in debug mode, only in release mode. I've tested it dozens of times in both modes - it always works in debug mode; always fails in release. Not sure why this is.
Secondly, you were right, it is getting an asException return value. The exception string is "Null pointer access."
The actual script file looks like this:
State only gets to 2. It appears that the first call to persist variable works, but the second one is not liked. In addition, if I comment out the second persist call, everything seems to work. If somehow _g was becoming NULL, I would think the Trace call would fail. Maybe it doesn't like the strings?
PersistVariable() in C++ looks like this:
Note that this function is not called by AngelScript directly. Instead, AngelScript calls a wrapper function which then calls this function.
I'll keep trying different things, but any more ideas?
Edited update: I've noticed that a call to trace(string&, int) immediately after persistvariable() will fail in the same way that a second persistvariable() call will fail. If I change Trace to an overload that looks like this: trace(int), it works. btw, I'm using asCScriptString.
[Edited by - Zoma on February 20, 2006 10:49:34 AM]
The error does not occur in debug mode, only in release mode. I've tested it dozens of times in both modes - it always works in debug mode; always fails in release. Not sure why this is.
Secondly, you were right, it is getting an asException return value. The exception string is "Null pointer access."
The actual script file looks like this:
int last_level = -1;int next_level = -1;int state = 0;void Init(){ state = 1; _g.PersistVariable("last_level", last_level); state = 2; _g.PersistVariable("next_level", next_level); state = 3; InitHelicopter(); state = 4; last_level = 1; next_level = 1; state = 5; Panel.SetCamera(cam1); state = 6;}void Update(){ _g.Trace("state", state); UpdatePanel(); UpdateHelicopter();}void UpdatePanel(){}State only gets to 2. It appears that the first call to persist variable works, but the second one is not liked. In addition, if I comment out the second persist call, everything seems to work. If somehow _g was becoming NULL, I would think the Trace call would fail. Maybe it doesn't like the strings?
PersistVariable() in C++ looks like this:
void PersistVariable(string& name, int value){ userdata->StoreVariable(name.c_str(), &value, sizeof(int));}Note that this function is not called by AngelScript directly. Instead, AngelScript calls a wrapper function which then calls this function.
I'll keep trying different things, but any more ideas?
Edited update: I've noticed that a call to trace(string&, int) immediately after persistvariable() will fail in the same way that a second persistvariable() call will fail. If I change Trace to an overload that looks like this: trace(int), it works. btw, I'm using asCScriptString.
[Edited by - Zoma on February 20, 2006 10:49:34 AM]
Author
Started looking at other posts about scriptstring, and I'm gonna try moving to 2.5.b now.
You might want to upgrade to 2.5.0c instead, but you probably know that by know.
Let me know if the problem persists after the upgrade.
Let me know if the problem persists after the upgrade.
Author
Yes, I got 2.5 C and it fixed the bug :)
I try not to upgrade unless I have to, as all my code has to be tested for any differences between versions. For example, the way I was using ExecuteString() in 2.4 stopped working in 2.5. The reason I did not get 2.5b was none of the listed changes appeared to affect me. The fix was listed for issues with VS 2005, and I'm using VS 2003. So I'm guessing it was a bug in 2003 as well.
Anyways, thanks again.
I try not to upgrade unless I have to, as all my code has to be tested for any differences between versions. For example, the way I was using ExecuteString() in 2.4 stopped working in 2.5. The reason I did not get 2.5b was none of the listed changes appeared to affect me. The fix was listed for issues with VS 2005, and I'm using VS 2003. So I'm guessing it was a bug in 2003 as well.
Anyways, thanks again.
I believe the fixes were the result of some of the extra error analysis provided by vs2005, not necessarily to get vs2005 to compile AS
Indeed, that particular bug was available for all versions of MSVC. But the improved debugging environment in MSVC2005 allowed me to detect it.
In general, you should always try to upgrade if the version number is the same except for the extra letter. When this is the case I have applied bug fixes but no other changes.
When the last digit changes, then I've changed stuff in the library that shouldn't affect the interface, i.e. maintain backwards compatibility. This might add new bugs, but it would be rare.
When the second digit changes, then I'm modifying the interface as well. In this case there is risks for new bugs, especially if I make major changes to the internals of the library, like in 2.4.0 -> 2.5.0.
When the first digit changes, then I've taken a completely new approach to the design, or it may mark a major milestone for the library. This should happen rarely, and you need to decide wether the new design fits your need or if you should stay with the current version.
Regards,
Andreas
In general, you should always try to upgrade if the version number is the same except for the extra letter. When this is the case I have applied bug fixes but no other changes.
When the last digit changes, then I've changed stuff in the library that shouldn't affect the interface, i.e. maintain backwards compatibility. This might add new bugs, but it would be rare.
When the second digit changes, then I'm modifying the interface as well. In this case there is risks for new bugs, especially if I make major changes to the internals of the library, like in 2.4.0 -> 2.5.0.
When the first digit changes, then I've taken a completely new approach to the design, or it may mark a major milestone for the library. This should happen rarely, and you need to decide wether the new design fits your need or if you should stay with the current version.
Regards,
Andreas
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
