🔒 Locked

AngelScript 2.8.0 Crashes on Linux

Started by droz Feb 15, 2007 at 1:44 PM 32 replies 5k views

Original Post

Feb 15, 2007 at 1:44 PM

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.

WitchLord

Feb 15, 2007 at 4:30 PM

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.

droz

Feb 15, 2007 at 4:36 PM

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).

WitchLord

Feb 15, 2007 at 4:49 PM

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.

droz

Feb 15, 2007 at 4:54 PM

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.

WitchLord

Feb 15, 2007 at 5:02 PM

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:

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

droz

Feb 15, 2007 at 5:10 PM

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.

WitchLord

Feb 15, 2007 at 5:13 PM

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:

#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.

WitchLord

Feb 15, 2007 at 5:30 PM

Do you feel like making another experiment? Try substituting the macros in as_memory.hh for the following:

#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[] ptr

If I'm right, the library will work again with this change.

droz

Feb 15, 2007 at 6:30 PM

Okay, that fixed it.

[Edited by - droz on February 15, 2007 7:30:17 PM]

droz

Feb 15, 2007 at 7:51 PM

After some more investigation it looks like the crash is isolated to the DELETEARRAY macro.

WitchLord

Feb 16, 2007 at 4:48 AM

Interesting. If the DELETEARRAY macro is failing it could only mean that &ptr[0] is not the same as ptr.

Oh well, when I get access to a Linux environment I'll perform some more experiments to understand what's wrong. In the mean time I've added a define AS_NO_USER_ALLOC that can be used to turn off the user defined memory functions. You can get this new version from the SVN (revision 110).

Thanks for helping me figure this out. It's terrible working in the blind, without being able to test it myself.

Regards,
Andreas

WitchLord

Feb 16, 2007 at 5:42 AM

I've made some more adjustments, would it be possible for you to try revision 111 from the SVN? It should work without defining the macro AS_NO_USER_ALLOC.

If it works I'll update version 2.8.0 with these changes so that others won't run into the same problems that you did.

Regards,
Andreas

droz

Feb 16, 2007 at 11:13 AM

Revision #111 works just fine, I haven't gotten time to really test it as I have to leave right now. But I did run through some of my scripts and none of them crashed.

Thanks for all your hard work,
Jeremy

WitchLord

Feb 16, 2007 at 11:42 AM

Thanks for confirming that it works. I'll upload a version 2.8.0a with these changes as soon as possible.

Let me know if you find any more errors.

Regards,
Andreas

droz

Feb 16, 2007 at 12:06 PM

No problem, I think the best thing to do at this point is port your tests to Linux. Tonight when I get some time I'll look into doing this as it would be the best method to see if everything works. If I do it I will send you updated source/makefiles if you'd like.

WitchLord

Feb 16, 2007 at 12:18 PM

That would be great. It is possible that some need some tweaking. Most of them should be working already though, because I used to test on SF's compile farm before they shut it down.

droz

Feb 16, 2007 at 2:01 PM

I got some time to work on it, I started with the feature test. I had to make some changes that I can send to you, but I'm getting a failure on two parts of the conversion test:

Line 566:

engine->ExecuteString(0, "ui8 = -12.3f;"); if( ui8 != asBYTE(-12.3f)  ) fail = true;

Line 595:

engine->ExecuteString(0, "ui16 = -12.3f;"); if( ui16 != asWORD(-12.3f)  ) fail = true;

Everything else passes after I defined __int64, and the I64 Constant isn't supported, so I changed it to LL when compiling with GCC.

droz

Feb 16, 2007 at 4:59 PM

I also made makefiles and the necessary changes to all of the samples to get them to compile under Linux. I'm not sure if you'd want to include these changes as it does complicate them a bit by adding ifdef's for linux.

You can get them at http://ww2.jeremyh.net/samples.zip, and see if you'd like to use them. I could put all the Linux functions into a separate source file if you'd like. That'd remove one if the ifdefs.

Jeremy

WitchLord

Feb 16, 2007 at 9:04 PM

That's really cool. I've wanted to have those samples converted to Linux for quite some time, but I never got around to work on it. I'll definitely include these changes in the sdk.

I think I want to move the platform differences to a separate file in the add_on directory, e.g. utils. That way the samples can concentrate on showing how to use AngelScript instead of this extra code.

It would be great if you could also send me the changes that you had to make to get the test_feature to work.

I'm curious about the failures in the conversion test though. What value are you getting from ui8 and from asBYTE(-12.3f)? This used to work in 2.7.1b, so it has to be related to the changes I made when adding support for the 64bit types.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.