Null pointer access (revision 824, PS3)

I personally implement Level (in my case, "Stage") functions as global functions rather than directly through an instance. Have C functions wrap the Level::instance()->Foo() stuff and just expose them globally.

I know, I am just so helpful aren't I?

It's been around 8 months that everything worked very well, I just updated to the latest revision and it crashes now. I hope it is because of the recent changes in as_callfunc_*.cpp.

It's been around 8 months that everything worked very well, I just updated to the latest revision and it crashes now. I hope it is because of the recent changes in as_callfunc_*.cpp.

Yes, i confirm, program works not properly. But after change back 'emms' to 'fninit' all works fine.

I knew the changes in as_callfunc had a high risk of breaking something. Unfortunately I had to take this risk in orde to make important improvements towards memory consumption and performance.

I'll need help in fixing these problems though, because I do not have a platform to test the ppc_64.cpp code. Can you help me find the error?

The change from fninit to emms was done because I got a bug report on the code breaking with fninit. Now I'm lost, which should really be used?

I said about as_callfunc_x86.cpp and revision 822.

I know. That's the only place fninit was used, still I don't understand why you need it to be fninit, and the other developer need it to be emms. Nor do I have any idea as to how I'm go to solve it for both of you.

The changes that must have broken the PS3 code is from revision 795.

diff for this version

I'm not quite sure yet, what the error is.

I know. That's the only place fninit was used, still I don't understand why you need it to be fninit, and the other developer need it to be emms. Nor do I have any idea as to how I'm go to solve it for both of you.

Don't bother about me, i change it myself, but you keep it mind for future.

About bug - don't know what happens, but program works not correct - many fails in places where it not can be, also this fails not in AS related code. Than i rebuild with 'emms'->'fninit' and program works without fails.

Also sorry that i wrote off-topic, missed that topic of the PS3.

Hello,

Before I updated to revision 824 (I was at 781 before) it was working and now it does not anymore, I guess it is because of the changes in as_callfunc_ppc_64.cpp which is used on PS3.

Level.fluidBarycenterSmooth = 0.5f;

and Level is defined as :

engine->RegisterGlobalFunction("LevelType& get_Level()", asFUNCTION(Level::instance), asCALL_CDECL);

Now this triggers a null pointer access exception each time Level is accessed.

Remi Gillig.

I reviewed the as_callfunc_ppc_64.cpp code, and for this very simple function I didn't see anything wrong. Maybe the problem is with property accessors, instead. Can you give the following code a try, just to see if it passes:

get_Level().fluidBarycenterSmooth = 0.5f;

That is, call the property accessor explicitly as a normal function. If the problem is with the property accessors rather than the native calling, then the scripts should be able to call the functions directly.

After testing the get property accessor that returns a reference on my Mac (with PPC simulation) and it worked correctly I took another look at the code changes done for PS3.

It seems that PS3 treats the return of pointers in a different manner. PS3 is using a 64bit Cell CPU, but the pointers are capped to 32bit.

One thing that was changed when unifying the code for native calling conventions was the introduction of


retQW >> 32;


for big endian platforms, when the actual returned value is only 32bits. It seems this cannot be done when the returned value is a pointer.

On the assumption that I'm right, I made a fix in revision 826. I'd appreciate it if you could let me know if that works for you. If it does, can you also let me know if the same fix is needed for XBox 360?

Hi,
I'm colleague of speps and i can confirm that the fix solve the issue, the same fix is needed on XBox 360. However I think the problem is more general because it happens with integer too.

Thanks for the confirmation. I'll have the same fix done for XBox 360. What do you mean it happens for integer too? The problem wasn't related to float or integer. The problem was when the function returns a pointer, regardless of that it pointed to.

I put a piece of code that explain the issue.

Declaration of the method:
r = engine->RegisterObjectMethod("LevelType", "int get_cameraID() const", asMETHODPR(Level, cameraID, () const, int), asCALL_THISCALL); assert(r>=0);
...
r = engine->RegisterObjectMethod("LevelType", "float get_currentTilt() const", asMETHODPR(Level, currentTilt, () const, float), asCALL_THISCALL); assert(r>=0);

Script:

int[] _array(6);
..
void update(float timeStep)
{
...
int cam = Level.cameraID; //real value is 1 return value is always 0
float tilt = Level.currentTilt; //real value 0.4 return value 0.4
...
uint size = _array.length(); //return value always 0
...
}


I tested quickly to add the cases of unsigned and integer to the shift that made for reference at the end of CallSystemFunctionNative. And it's good the function return the true value, but I think it's not the better fix.

as_callfunc_ppc_64.cpp - line 753:
#if AS_PTR_SIZE == 1
else if( descr->returnType.IsUnsignedType() || descr->returnType.IsIntegerType() || descr->returnType.IsReference() || descr->returnType.IsObjectHandle() )
{
// Move the pointer to the higher bits to compensate for the adjustment done outside
retQW <<= 32;
}
#endif

I can't test anything before next week because I have to work on an other side of the project. I think continue my test next wednesday.

I understand. So the original problem was not just for pointers, but really for all types that occupy only 1 DWORD (with the exception of floats). This puts things in a different light, and I'll revisit the solution. Thanks for the clarification.

I've fixed this in revision 860, for both PS3 and XBox360. Let me know if there are any further problems.

Thanks,

Andreas