Jump to content
  • Advertisement
Sign in to follow this  
ruphert

Crash on linux (gcc 4.3?)

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey,

After switching to Angelscript 2.27.1 I get this crash on linux. But it happens only if I compile on my machine with gcc 4.3.

On gcc 4.7 it works fine.

 

The crash happens right after calling a second function, first script whatsoever.

Any idea what this is?

The array is empty and the index is 1 in this case.

KAGdedi: ../../source/as_array.h:158: T& asCArray<T>::operator[](size_t) [with T = asCScriptFunction*]: Assertion `index < length' failed.

Program received signal SIGABRT, Aborted.
0xf7fdb425 in __kernel_vsyscall ()
(gdb) bt
#0  0xf7fdb425 in __kernel_vsyscall ()
#1  0xf7d101df in raise () from /lib/i386-linux-gnu/libc.so.6
#2  0xf7d13825 in abort () from /lib/i386-linux-gnu/libc.so.6
#3  0xf7d09085 in ?? () from /lib/i386-linux-gnu/libc.so.6
#4  0xf7d09137 in __assert_fail () from /lib/i386-linux-gnu/libc.so.6
#5  0xf737929d in asCArray<asCScriptFunction*>::operator[](unsigned int) () from Base/../libJuxta_dedi.so
#6  0xf73ce434 in CallSystemFunction(int, asCContext*, void*) () from Base/../libJuxta_dedi.so
#7  0xf7372b34 in asCContext::ExecuteNext() () from Base/../libJuxta_dedi.so
#8  0xf737044a in asCContext::Execute() () from Base/../libJuxta_dedi.so
#9  0xf70b131e in asScript::ExecuteWithDebug (this=0x8225530, ctx=0x81ec0e8) at ../Scripting/asScript.cpp:385
#10 0xf70b1eeb in asScript::executeFunctionByName (this=0x8225530, name=...) at ../Scripting/asScript.cpp:506
#11 0xf70b60a2 in asScriptManager::runScriptFromFile (this=0x80d0e54, fileName=..., entryFunction=..., fileMatch=false) at ../Scripting/asScriptManager.cpp:766
#12 0xf70ac39d in CScript::RunScriptFromFile (this=0x80d0e50, fileName=..., entryFunction=..., fileMatch=<optimized out>) at ../Scripting/Script.cpp:89
#13 0xf6f2b943 in CGame::Run (this=0x8175bd8, argc=1, argv=0xffffd214) at ../Game/GameDLL.cpp:475
#14 0xf6f1620f in GameDLLInit (ie=..., argc=1, argv=0xffffd214) at ../Game/GameDLL.cpp:94
#15 0x0804c078 in CApplication::LoadGameDLL (this=0x80cc088, filename=0x80cc2f4 "Base/../libJuxta_dedi.so", argc=1, argv=0xffffd214) at ../App/main.cpp:346
#16 0x0804e8c5 in CApplication::Run (this=0x80cc088, argc=1, argv=0xffffd214) at ../App/main.cpp:228
#17 0x0804c3ed in main (argc=1, argv=0xffffd214) at ../App/main.cpp:623
(gdb) 

Share this post


Link to post
Share on other sites
Advertisement

It's obviously some incompatibility between gnuc versions. The last change I made knowingly for this was in version 2.26.2 where I fixed the native calling conventions for MinGW 4.7, though I believe you were using 2.26.2 before the upgrade so that shouldn't be the cause now.

 

I'll try to see if I can figure out what may have caused this problem. With version 2.26.2 it was working with both gnuc versions, right?

Share this post


Link to post
Share on other sites

Comparing the code from version 2.26.2 and 2.27.1 I can really only identify one possible cause, and that is the change done to the thread manager. It is possible that the use of thread local storage doesn't work correctly in gnuc 4.3, and that

 

Would it be possible for you to make a test using the library version 2.27.1, but with the old code for as_thread.cpp and as_thread.h? It shouldn't require any code changes, just a copy of the mentioned files from 2.26.2 version to the 2.27.1 version.

 

If we can prove this is the cause I'll add a compile time switch to use the old way in the older gnuc compiler.

Share this post


Link to post
Share on other sites

Its working. The issue was unrelated to gcc. It turns out some old or seemingly random angelscript code was used in creating the lib. A full clean of angelscript and rebuilding again helped.

Share this post


Link to post
Share on other sites

No, the memory leak remains. I will need to isolate the problem somehow cause right now there is a 16kb leak on every initialized script.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!