I just had a crash in the memcopy at line 338 in CallSystemFunction in as_callfunc_x86.cpp. What would be the best way to find out what's wrong - and where ? :) (I assume it's in a constructor/destructor/assignment operator - I believe these are the "system functions" ..?) Is there any kind of human-readable script-callstack to show me where I farked it up ? :)

I'm implementing better debugging support right now. It will allow the registration of a callback function that will be called for each script line. It will allow you to set break points in the scripts. I will also implement methods for enumerating the callstack so that you can know which script functions were called.

Later on I will also allow the stack memory to be analyzed, so that the values of the variables can be checked.

CallSystemFunction() is used when calling any function registered by the application, not just the behaviour functions.

-------

Looking at the line 338, I can tell you that something went wrong when calling a registered function that takes a registered object type by value as a parameter. Possible causes for the crash, is the size of paramBuffer which might be too small to fit all the parameters to this function, or the size of the object is computed wrong in GetSizeInMemoryBytes(). It might also be a bug in AngelScript, where the pointer in args+spos is invalid.

Can you recommend me any way so I can debug it now..?
I've jumped to 2.0, but if I can't get this crash out of the way soon I'll switch back to 1.10.1d for the time being..
I't really frustrating not being able to work on BH 'cause of this ;)

I must have registered something incorrectly I guess,
but I really don't know where to start looking :(

You might register a simple debug function, that you could call from various locations in the script to verify how far the execution gets. An example would be:

void DebugInfo(){  asIScriptContext *ctx = asGetActiveContext();  int line = ctx->GetCurrentLineNumber();  int func = ctx->GetCurrentFunction();  printf("%s::%s - %d\n", engine->GetModuleNameFromIndex(func>>16),                          engine->GetFunctionDeclaration(func),                          line);}

You could also set a break point in the function at the location where memcpy is called, then examine descr->name. It should let you know the name of the function that is causing the crash.

I think that should let you get started on finding the problem.

---
Oops, I forgot that GetCurrentFunction() currently doesn't return information about the module. It's a bug in AS 2.0.0 (discovered Tomas Stepanek). If you need that information you could change the implementation in the method to add module->moduleID to the function id returned.
---

Quote: Original post by WitchLord
You could also set a break point in the function at the location where memcpy is called, then examine descr->name. It should let you know the name of the function that is causing the crash.

yup, that's what I did, I know which function - just not which part of it...
Damn, I guess I'll just have to take stuff out of that function until it works - then I know what the problem would be...

Could you tell me how you registered the function that fails? AS has a problem with one of the parameters, or maybe it just has too many parameters.

Quote: Original post by WitchLord
Could you tell me how you registered the function that fails? AS has a problem with one of the parameters, or maybe it just has too many parameters.

It seems something has changed :
my function used to be registered as
"void DrawGrid(GridParameters ∈, string)"
which crashes (but used to work in the old AS-version).

"void DrawGrid(GridParameters ∈, string ∈)"
seems to work afaict right now though.

Should strings always be registered by reference ?
In other places I did the same (f.e. LoadTexture("string")), but that didn't crash.. so it's probably a weird combination..?

AS 2.0.0 changed the way objects are handled internally, so the code for passing objects by value to system functions had to be altered. It's possible that some bug slipped through here.

I'll verify if that is the case here.