Linux i686 and x86-64
oh, right, how could I miss that.. Note that the address gets mangled with AS_MAX_PORTABILITY defined, so my guess is that it's a bug in the VM itself
BTW, the very same thing happens in win64:
EDIT: It's normal that it ends in the non-generic function, because our code uses the generic function just to call the normal function.
[Edited by - jal_ on February 8, 2009 6:17:51 AM]
Quote:
> game_x64.dll!objectString_Addref(asstring_t * obj=0x01e467a001e467a0) Line 859 + 0xb bytes C
game_x64.dll!objectString_asGeneric_Addref(void * gen=0x000000000012eeb8) Line 864 C
angelwrap_x64.dll!asCScriptEngine::CallObjectMethod(void * obj=0x01e467a001e467a0, asSSystemFunctionInterface * i=0x000000000215ebe0, asCScriptFunction * s=0x000000000217bbd0) Line 2713 C++
angelwrap_x64.dll!asCScriptEngine::CallObjectMethod(void * obj=0x01e467a001e467a0, int func=41) Line 2659 C++
angelwrap_x64.dll!asCContext::ExecuteNext() Line 2308 C++
angelwrap_x64.dll!asCContext::Execute() Line 1096 + 0xa bytes C++
angelwrap_x64.dll!asCModule::CallInit() Line 218 C++
angelwrap_x64.dll!asCModule::Build() Line 170 C++
angelwrap_x64.dll!qasBuildModule(int engineHandle=0, const char * module=0x0000000002cad868) Line 630 C++
Quote:
+ obj 0x01e467a001e467a0 {buffer=??? len=??? asRefCount=??? ...} asstring_t *
EDIT: It's normal that it ends in the non-generic function, because our code uses the generic function just to call the normal function.
[Edited by - jal_ on February 8, 2009 6:17:51 AM]
Quote:
The problem is that with gcc 3.3.4 the program crashed very soon after AS initialization, disabling multithreading fixed that, hence the second patch.
Did it crash due to asCAtomic, or something else? If it was due to asCAtomic, then perhaps it works if the critical sections are used instead?
I'd prefer not to disable the multithreading support by default. If it is possible to get multithreading working then it should be turned on by default (even if it hurts performance).
I'll add a section in the manual on how to get the most performance out of the library, e.g. by compiling the library with asNO_THREADS.
I'll look into the problem with the 64bit platforms. It's most likely a bad type cast somewhere. The problem is that I don't have a 64bit platform to test this on, but I've asked droz for access to his VPS, so hopefully I should be able to fix this soon enough.
Quote:Original post by WitchLordQuote:
The problem is that with gcc 3.3.4 the program crashed very soon after AS initialization, disabling multithreading fixed that, hence the second patch.
Did it crash due to asCAtomic, or something else? If it was due to asCAtomic, then perhaps it works if the critical sections are used instead?
Here's the backtrace:
#0 0x00000041 in ?? ()#1 0xb7bb9662 in ScriptStructFactory (objType=0x8401ad0, engine=0x83a8fb0) at ../../source/as_scriptstruct.cpp:69#2 0xb7bbf674 in asCArrayObject::Construct (this=0x83ee468, buf=0x8446568, start=0, end=3) at ../../source/as_arrayobject.cpp:452#3 0xb7bbf544 in asCArrayObject::CreateBuffer (this=0x83ee468, buf=0x83ee478, numElements=3) at ../../source/as_arrayobject.cpp:420#4 0xb7bbee23 in asCArrayObject (this=0x83ee468, length=3, ot=0x840c7b0) at ../../source/as_arrayobject.cpp:302#5 0xb7bbe2ef in ArrayObjectFactory2 (ot=0x840c7b0, length=3) at ../../source/as_arrayobject.cpp:56#6 0xb7bd2996 in endcopy () at ../../source/as_callfunc_x86.cpp:565#7 0xb7bd22a3 in CallSystemFunction (id=2, context=0x8410dd8, objectPointer=0x0) at ../../source/as_callfunc_x86.cpp:324#8 0xb7bf9bc0 in asCContext::ExecuteNext (this=0x8410dd8) at ../../source/as_context.cpp:2044#9 0xb7bf834d in asCContext::Execute (this=0x8410dd8) at ../../source/as_context.cpp:1096#10 0xb7c05632 in asCModule::CallInit (this=0x83eee88) at ../../source/as_module.cpp:217#11 0xb7c05415 in asCModule::Build (this=0x83eee88) at ../../source/as_module.cpp:168jal: figured :)
I just checked in some changes (rev 354) that I hope fixes both of your problems.
First of all I changed as_atomic.cpp to use critical sections on GCC for versions older than 4.1. This will avoid using the kernel functions altogether, at the price of slower performance. (Remember to turn off multithreading if you don't need it)
I also found a couple of places where the compiler was generating incorrect bytecode for 64bit platforms. Hopefully with these fixes you won't get the SEGV crashes anymore.
First of all I changed as_atomic.cpp to use critical sections on GCC for versions older than 4.1. This will avoid using the kernel functions altogether, at the price of slower performance. (Remember to turn off multithreading if you don't need it)
I also found a couple of places where the compiler was generating incorrect bytecode for 64bit platforms. Hopefully with these fixes you won't get the SEGV crashes anymore.
Thanks! I'll check out the x64 changes asap. As for the atomic stuff, you forgot to add the
section into the block ;) Not sure if it really belongs to the __APPLE__ one.. After fixing this section, things seem to be working fine again
#if !( ( (__GNUC__ == 4) && (__GNUC_MINOR__ >= 1) || __GNUC__ > 4) ) // Only with GCC 4.1 was the atomic instructions available #define AS_NO_ATOMIC #endifsection into the
#elif defined(__linux__)
Due to the change to the Makefile, linking a library with libangelscript.a produces an error:
/usr/bin/ld: ../libsrcs/angelscript/angelSVN/sdk/angelscript/lib/libangelscript.a(as_scriptengine.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
../libsrcs/angelscript/angelSVN/sdk/angelscript/lib/libangelscript.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
/usr/bin/ld: ../libsrcs/angelscript/angelSVN/sdk/angelscript/lib/libangelscript.a(as_scriptengine.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
../libsrcs/angelscript/angelSVN/sdk/angelscript/lib/libangelscript.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
I'm not sure what it may be. gargltk has just finished implementing the native support for 64bit Linux and he didn't report this problem.
adding back the -fPIc flag fixed the problem for me, not sure why it got removed in the first place..
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
