# Angelscript on Raspberry Pi

This topic is 1831 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

That worked, thanks! Now TestCDecl_ClassK passed. The next error is appearing when calling the armFuncObjLast function, but since I still haven´t worked on it that´s to be expected.

I´ll let you know how it goes.

##### Share on other sites
(and after almost 20 days.....)

All tests passed succesfully!!!

I only modified the armFunc, armFuncR0 and armFuncObjLast functions, but the others passed their respective tests too... what can that mean?

What´s the next step? I guess trying to pass the tests that were commented out.

I´ll be awating instructions!

##### Share on other sites
It's quite possible that my tests don't cover all situations required to fully test the ABI. I'll take a look at those later to see if the tests really should cover the other ARM funcs too. But I wouldn't worry too much about that. We'll have to make adjustments later as the problems are discovered.

I suggest running the rest of the test suite to see if there is nothing seriously wrong. If you don't find any errors, I'd like to receive the code you've changed so far so I can merge it with the SDK.

##### Share on other sites
Ok, I´ll run the others tests. There´s also one little thing that´s bugging me, so I´ll have a few more rounds with the code.
I´ll be back!

##### Share on other sites
I´ve got some errors with the other tests:

The scriptbuilder test reports an "unexpected token "[" at 38,2 and 39,2 and fails. The I get a segmentation fault.

I commented out the scriptbuilder test and scriptMath and serializer tests passed, but then the GC complaint that it couldn´t free an object of type "_builtin_function_" because it was being kept alive by the app.

Then the ScriptHandle and ScriptArray tests passed and I got a segmentation fault.

I tried commenting the first 4 tests (debugger, scriptBuilder, Math and serializer) and I got the GC complaints at the beginning. Then ScriptArray and ScriptHandle passes, the segmentation fault.

Any ideas of where to look for the problem? I´m guessing the asm routines?

EDIT: No, it´s not the asm routines. I commented out only the first test, then the scriptbuilder fails with the "unexpected token" message and then I get the seg fault, with no asm functione being called. Edited by Tzarls

##### Share on other sites
I had similar problems when testing on Linux before the release of 2.25.2. These were all fixed, so I suggest you merge your changes with the latest release and see if the problems remains.

##### Share on other sites
Tried with AS 2.25.2, and got almost the same behaviour. There´s no more "unexpected token" error, but after a couple of tests I get the "CG couldn´t free object of type "_builtin_function_" and the a segmentation fault.

##### Share on other sites
It could be a platform specific problem. Without debugging the code myself it's really hard to guess what is wrong.

Can you skip this test and see how many of the others that work successfully?

##### Share on other sites
Ok, just tested disabling some of the tests:

- If I disable all the first 7 tests (the Addon tests) then the seg fault is gone until the TestRefArgument test is executed. It produces a seg fault.

- There is a number of tests that produce assertion failures. These are:

TestScriptClassMethod
TestScriptString
TestCompiler
TestRegisterType
TestVector3
TestStdString

I guess these assert failures mean I still have to tweak the code to make it work. But what about the seg faults caused by the addons?

##### Share on other sites
It's possible the segfaults are due to the code for the native calling conventions are not properly cleaning up the stack after returning, or that the armFuncs don't keep the value of registers that are not supposed to be modified. It could also be something else entirely. It is almost certainly platform specific though as these problems don't happen on other platforms.

The only way to know for sure is to debug and find the cause.

##### Share on other sites
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.

##### Share on other sites
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.

##### Share on other sites
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.

##### Share on other sites
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?

##### Share on other sites
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.

##### Share on other sites
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?

##### Share on other sites
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.

##### Share on other sites
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).

##### Share on other sites
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.

##### Share on other sites
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?

##### Share on other sites
It should be received as a double. The script will call the 'bool get(const string &in, double&out) const' overloaded method on the dictionary object. The C++ method will receive a pointer to a double that it will fill with the value. Then the script will convert that double to a float and assign it to the f variable.

That gives me an idea of the problem. When you check if a parameter is a float or double, do you also check to make sure it is not a reference? I.e. !descr->parameterTypes[n].IsReference()?

If the argument is a reference, it should be treated as a integer as it is the address that is being passed to the function, not the float value.

I think this was my mistake, I forgot to tell you about checking for references earlier.

##### Share on other sites
Added the check for references, and the seg fault is gone! I still have some tests that fail and the GC still complaints about not being able to release an object of type "_builtin_function_" after the serializer test is passed.

The tests that are still failling are:

TestScriptString
TestRegisterType
TestVector3
TestStdString

Can you see anything in common between these tests?

The TestCompiler is also crashing - what´s more, this one even crashes the app but I have a very good idea of what´s wrong and how ti fix it.

I´ll begin by looking at the TestScriptString. It fails here:

ExecuteString(engine, "print(1.2 + \"a\")"); if( printOutput != "1.2a") { printf("Get '%s'\n", printOutput.c_str()); TEST_FAILED; } Edited by Tzarls

##### Share on other sites
Does it manage to print something? What does it print? As the test shows, the expected output is "1.2a", what did you get?

The test will call the following registered function:

 static CScriptString *AddFloatString(float f, const CScriptString &str) { char buf[100]; sprintf(buf, "%g", f); return new CScriptString(buf + str.buffer); } 

So it should pass the float f in s0, the string pointer str in r0, and then return the new string pointer in r0. Is this what is happening?

The function is registered with asCALL_CDECL_OBJLAST, so perhaps that may be the reason for the failure.

All of the tests that fail actually test a lot of different functionality, so I need to know on which particular test that they fail on. The best would be if you can tell me the line number where the test is reporting that it is failing. Then I can have a look at the code and try to think of what can be wrong.

Regards,
Andreas Edited by Andreas Jonsson

##### Share on other sites
This test first calls (ICC_CDECL)

string@ _string_factory_(const int, const uint8&)

Returns an object, and the calls (ICC_CDECL_OBJLAST)

string@ string::opAdd_r(double) const

This also returns an object. Then it prints:

Get '11.8998a'
Failed on line 254... (which is the last line of the code I copied in my previous post)

##### Share on other sites
Yes. It's clear that the problem is that the function didn't receive the correct value on the float argument.

It would appear that armFuncObjLast is not working properly. It's setting the string pointer in the r0 register as it should, but it is not setting s0 with the float value as it should.