I´ll try to find the cause, but I´ll need some information, specially since my asm is very very basic.

What do you mean with "cleaning up the stack"? I guess it means setting the stack pointer to where it was when it entered the function? I was thinking that comparing the sp´s value right after the push with the value right before the pop at the end of the function should give the same result, right? If results match, does it mean the stack is being cleared properly?

I´ve had care to keep and restore the values of the registers I use in the functions, and to only use registers marked as "general purpose" or "scratch", BTW.

Yes. I mean exactly that. Making sure the stackpointer is restored to its correct location. Depending on the ABI this may mean that it should be returned to the same position it was when going in to the function, or it may be that the function arguments should be popped by the called function. Sometimes it is only the implicit return pointer that should be popped, leaving the rest of the arguments for the calling function to clean up.

If you backup the registers and stick to general purpose or scratch registers then the problem is most likely to be just the stackpointer.

You mentioned earlier that you access your environment with VPN. If you'd like to give me access to the environment I may be able to do some investigation on my own. I don't promise anything, but I may find a little time to look into this.

I´ve been checking the stack pointer´s values and at least with the functions I modified those values are the same after the push and before the pop.

Let me know where to send you the information about remote accessing my RPi and any other information you´d think will be useful and then you can log in any time you want - just let me know when you´re using it so I don´t interfere.

you can send it to my e-mail: andreas@angelcode.com

Of course, I'll need to know the directory where you're testing so I can have a look at the code. and do some tests. Also, I'll need to know what compilation flags you use. Or do you simply call make for the gnuc projects?

I assume I'll have access via SSH or Telnet, right?

I use Ultra-VNC of Tight-VNC to acces the RPi. For compilation I just use the default gnuc projects - I only modified the AS makefile to make it include the correct armfunc file.

I´ll send you the details to your email.

FWIW, the test_addon_dictionary fails when the script tries to call a native function passing a string by value. The passing of an int and a handle work as expected... maybe we need to add another check for that situation?

This might be that AngelScript tries to call the destructor on the string value after the function returns. If the function already destroyed the string before returning, this could possibly cause a seg fault.

Try commenting out the #define AS_CALLEE_DESTROY_OBJ_BY_VAL on line 741 in as_config.h.

Nope, didn´t help. I found the seg fault is happening at line 199 of file scriptdictionary.cpp.

memcpy (value, &it->second.valueInt, size);

It happens the third time this function is called, when passing "c". I suspect "value" isn´t getting the right, well, value (no pun intended).

Sounds like a problem related to the variable argument type. This is a special type, in that in AngelScript is will look like a single argument, but for the native function it will actually be 2 arguments, the first is a pointer, and the second is an int.

The original as_callfunc_arm.cpp should have been working with this, but depending on the changes you made, you may have accidentally broken it.

You can identify the variable argument type with the following condition:


if( descr->parameterTypes[n].GetTokenType() == ttQuestion )
{
// Treat the variable argument type as two separate args, one pointer and one int
...
}


As both the pointer and the int will go to the generic paramBuffer, it should just be a matter of copying both normally. Remember, even though this type would be identified as taking up 64bits on the stack with GetSizeOnStackDWords() it shouldn't be aligned to a 64bit boundary.

Andreas:

Apparently I was wrong about the point where the failure happens. On one hand I wasn´t checking for the variable argument type, but that wasnñt causing the problem (I´ve added acheck for that nevertheless). The seg fault is caused by this part of the script:

// Test float with the dictionary
" float f = 300; \n"
" dict.set('c', f); \n"
" dict.get('c', f); \n" // Seg fault
" assert(f == 300); \n"

The float is being received by the app as a double, BTW. Any ideas?