AngelScript 2.8.0 Crashes on Linux
Author
2.8.0 Crashes on linux when you try to create the script engine here is the crash backtrace:
*** glibc detected *** /home/jeremy/Projects/aws/src/aws: free(): invalid pointer: 0x080da564 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb7de28bd]
/lib/tls/i686/cmov/libc.so.6(__libc_free+0x84)[0xb7de2a44]
/home/jeremy/Projects/aws/src/aws[0x8079a64]
/home/jeremy/Projects/aws/src/aws[0x8078fb7]
/home/jeremy/Projects/aws/src/aws[0x8070c11]
/home/jeremy/Projects/aws/src/aws[0x807efc9]
/home/jeremy/Projects/aws/src/aws[0x807692d]
/home/jeremy/Projects/aws/src/aws[0x8076c44]
/home/jeremy/Projects/aws/src/aws[0x804e070]
/home/jeremy/Projects/aws/src/aws(__gxx_personality_v0+0x178)[0x8049c70]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc)[0xb7d918cc]
/home/jeremy/Projects/aws/src/aws(__gxx_personality_v0+0x69)[0x8049b61]
======= Memory map: ========
08048000-080d9000 r-xp 00000000 03:02 3375118 /home/jeremy/Projects/aws/src/aws
080d9000-080da000 rw-p 00090000 03:02 3375118 /home/jeremy/Projects/aws/src/aws
080da000-080fb000 rw-p 080da000 00:00 0 [heap]
b7c00000-b7c21000 rw-p b7c00000 00:00 0
b7c21000-b7d00000 ---p b7c21000 00:00 0
b7d7b000-b7d7c000 rw-p b7d7b000 00:00 0
b7d7c000-b7ea9000 r-xp 00000000 03:02 4538706 /lib/tls/i686/cmov/libc-2.4.so
b7ea9000-b7eab000 r--p 0012c000 03:02 4538706 /lib/tls/i686/cmov/libc-2.4.so
b7eab000-b7ead000 rw-p 0012e000 03:02 4538706 /lib/tls/i686/cmov/libc-2.4.so
b7ead000-b7eb1000 rw-p b7ead000 00:00 0
b7eb1000-b7ebb000 r-xp 00000000 03:02 4505667 /lib/libgcc_s.so.1
b7ebb000-b7ebc000 rw-p 00009000 03:02 4505667 /lib/libgcc_s.so.1
b7ebc000-b7ee0000 r-xp 00000000 03:02 4538710 /lib/tls/i686/cmov/libm-2.4.so
b7ee0000-b7ee2000 rw-p 00023000 03:02 4538710 /lib/tls/i686/cmov/libm-2.4.so
b7ee2000-b7fb6000 r-xp 00000000 03:02 2508689 /usr/lib/libstdc++.so.6.0.8
b7fb6000-b7fb9000 r--p 000d4000 03:02 2508689 /usr/lib/libstdc++.so.6.0.8
b7fb9000-b7fbb000 rw-p 000d7000 03:02 2508689 /usr/lib/libstdc++.so.6.0.8
b7fbb000-b7fc1000 rw-p b7fbb000 00:00 0
b7fd1000-b7fd3000 rw-p b7fd1000 00:00 0
b7fd3000-b7fec000 r-xp 00000000 03:02 4505604 /lib/ld-2.4.so
b7fec000-b7fee000 rw-p 00018000 03:02 4505604 /lib/ld-2.4.so
bf845000-bf85a000 rw-p bf845000 00:00 0 [stack]
ffffe000-fffff000 ---p 00000000 00:00 0 [vdso]
If you need any more information please let me know.
I don't see any trace of AngelScript in that backtrace. But I'll take a look at it anyway.
I have to confess that the AngelScript 2.8.0 release was bit rushed, since I ran out of time and felt that it had been too long since the last release.
I have to confess that the AngelScript 2.8.0 release was bit rushed, since I ran out of time and felt that it had been too long since the last release.
Author
I ran a debugger and it's definitely crashing in asCreateScriptEngine. I toggled a breakpoint before it, then stepped over and it segfaults in __kernel_vsyscall() (not sure how helpful that is).
Unfortunately I do not have access to any Linux environment at the moment to test AngelScript on. SourceForge's compile farm is down, and it looks like it has been for about 10 days, so I do not know when I'll have access to it again.
I need help from someone with Linux access to figure out what's wrong.
Did you use AngelScript before 2.8.0? Or is this the first time you're giving it a try? Would you mind giving 2.7.1b a try to see if that works?
Have you tried stepping into asCreateScriptEngine? To see where exactly it crashes?
It looks like it crashes as it's trying to free memory, but I don't know which one it may be.
I need help from someone with Linux access to figure out what's wrong.
Did you use AngelScript before 2.8.0? Or is this the first time you're giving it a try? Would you mind giving 2.7.1b a try to see if that works?
Have you tried stepping into asCreateScriptEngine? To see where exactly it crashes?
It looks like it crashes as it's trying to free memory, but I don't know which one it may be.
Author
I'm not very good with gdb and don't know how to step into the library, but I can if you can give me a brief run down on how.
Yes, I used the last version and it works just fine.
I won't have time today, but if you need I can give you a account on my linux server, but probably not until the weekend.
Yes, I used the last version and it works just fine.
I won't have time today, but if you need I can give you a account on my linux server, but probably not until the weekend.
I'm not very good with gdb either, but if I recall correctly you use n to step over function, and s to step into functions.
Since the last version worked, then my guess the problem may have something to do with the way I changed everything to use the registerable memory management functions.
You may try registering your own memory functions with asSetGlobalMemoryFunctions() to see if that may fix the problem. The memory functions should have the same signatures as malloc() and free().
Perhaps start with something simple like:
Having access to your Linux server may come in handy. Especially if we can't figure out this problem in any other way. Thanks for the offer.
Regards,
Andreas
Since the last version worked, then my guess the problem may have something to do with the way I changed everything to use the registerable memory management functions.
You may try registering your own memory functions with asSetGlobalMemoryFunctions() to see if that may fix the problem. The memory functions should have the same signatures as malloc() and free().
Perhaps start with something simple like:
void *myAlloc(size_t size){ return new char[size];}void myFree(void *ptr){ delete[] ptr;}asSetGlobalMemoryFunctions(myAlloc, myFree);Having access to your Linux server may come in handy. Especially if we can't figure out this problem in any other way. Thanks for the offer.
Regards,
Andreas
Author
I was able to step into asCreateScriptEngine it crashes when you create the asIScriptEngine, I wasn't able to get anymore info than that because it's crashing in NEW.
It's probably crashing somewhere inside the asCScriptEngine constructor. Can you try setting a break point inside the constructor and then go from there?
You should be able to set the break point with "b as_scriptengine.cpp:149".
I'm guessing the crash is due to differences in how the placement new() works on MSVC++ and gnuc. I'm using a few different macros to perform the allocations and deallocations:
One of these are probably not working on gnuc and needs to be adjusted.
You should be able to set the break point with "b as_scriptengine.cpp:149".
I'm guessing the crash is due to differences in how the placement new() works on MSVC++ and gnuc. I'm using a few different macros to perform the allocations and deallocations:
#define NEW(x) new(userAlloc(sizeof(x))) x#define NEWARRAY(x,cnt) (x*)userAlloc(sizeof(x)*cnt)#define NEWOBJARRAY(x,cnt) new(userAlloc(sizeof(x)*cnt+sizeof(size_t))) x[cnt]#define DELETE(ptr,x) {void *tmp = ptr; (ptr)->~x(); userFree(tmp);}#define DELETEARRAY(ptr) userFree(&ptr[0])#define DELETEOBJARRAY(ptr) userFree(((char*)&ptr[0])-sizeof(size_t))One of these are probably not working on gnuc and needs to be adjusted.
Do you feel like making another experiment? Try substituting the macros in as_memory.hh for the following:
If I'm right, the library will work again with this change.
#define NEW(x) new x#define NEWARRAY(x,cnt) new x[cnt]#define NEWOBJARRAY(x,cnt) new x[cnt]#define DELETE(ptr,x) delete ptr#define DELETEARRAY(ptr) delete[] ptr#define DELETEOBJARRAY(ptr) delete[] ptrIf I'm right, the library will work again with this change.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement