🔒 Locked

AngelScript 2.10.0 released

Started by WitchLord Sep 23, 2007 at 2:13 PM 25 replies 8.1k views

Original Post

Sep 23, 2007 at 2:13 PM

I've uploaded a new update for AngelScript. This time I've improved the AngelScript garbage collector so that it can be allowed to take care of application registered types as well. Most registered types probably won't need this, but if you intend to register container classes that can form circular references, then you may want to look into this. For the GC to be able to take care of the registered types a couple of new behaviours must be implemented and registered for the types. Now that registered types can be handled by the script engine, I decided to move the built-in any type out of the core library and into an add-on instead. It's thus no longer a built-in type and can be registered if desired by the application. For the next version I plan on improving the interface for registering types and functions. Once it is complete, it will be easier to catch and pinpoint mistakes in the registration so that less time is spent on debugging memory leaks or stack corruptions. Regards, Andreas

mono2k

Sep 24, 2007 at 8:15 AM

Thanks, good work!

What about "ExecuteString() shouldn't lock dynamic config groups" feature? Is it in a near future?

WitchLord

Sep 29, 2007 at 10:17 AM

It is quite high on the to-do list. I can't give any dates, but it is something I want to do soon.

kunitoki

Oct 2, 2007 at 2:27 PM

i've experienced some problems with new WIP version. i'm on a "roxxorx 2.6.22-kamikaze9 SMP i686 Intel(R) Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux" with gcc 4.1.2

- first of all, the test_feature application wouln't compile anymore on gcc-linux. we have some functions not present anymore (or moved like the any class) and some tests not in the makefile. i'll try to fix and send you an updated version of the test (which i use sometimes to test as behaviour).

- secondly, instantiate script classes outside of function (in main context) crashes angeljuice or a simple example like this:

#include "angelscript.h"void TestCrash{	asIScriptEngine *engine = asCreateScriptEngine(ANGELSCRIPT_VERSION);	engine->ExecuteString(0, "class XXX { int a; }; XXX b;");	engine->Release();}

produce:

*** glibc detected *** ./testgnuc: double free or corruption (fasttop): 0x0814d210 ***======= Backtrace: =========/lib/libc.so.6[0xa7d417ab]/lib/libc.so.6(__libc_free+0x7e)[0xa7d42d2f]/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6(_ZdlPv+0x21)[0xa7ed7af9]./testgnuc[0x8097561]./testgnuc[0x8097586]./testgnuc[0x80975d6]./testgnuc[0x8097700]./testgnuc[0x809772a]./testgnuc[0x8096691]./testgnuc[0x80a684c]./testgnuc[0x80c3291]./testgnuc[0x80c2fa0]./testgnuc[0x80c306e]./testgnuc[0x80c309a]/lib/libc.so.6(exit+0xdc)[0xa7d0aa54]/lib/libc.so.6(__libc_start_main+0xe4)[0xa7cf582c]./testgnuc(__gxx_personality_v0+0xb9)[0x8049e81]======= Memory map: ========08048000-08145000 r-xp 00000000 08:04 3604482    /home/kunitoki/Projects/angelscript/tests/test_feature/bin/testgnuc08145000-08146000 r--p 000fc000 08:04 3604482    /home/kunitoki/Projects/angelscript/tests/test_feature/bin/testgnuc08146000-08147000 rw-p 000fd000 08:04 3604482    /home/kunitoki/Projects/angelscript/tests/test_feature/bin/testgnuc08147000-08171000 rw-p 08147000 00:00 0          [heap]a7b00000-a7b21000 rw-p a7b00000 00:00 0 a7b21000-a7c00000 ---p a7b21000 00:00 0 a7cde000-a7ce0000 rw-p a7cde000 00:00 0 a7ce0000-a7dfb000 r-xp 00000000 08:03 2639004    /lib/libc-2.5.soa7dfb000-a7dfd000 r--p 0011b000 08:03 2639004    /lib/libc-2.5.soa7dfd000-a7dfe000 rw-p 0011d000 08:03 2639004    /lib/libc-2.5.soa7dfe000-a7e01000 rw-p a7dfe000 00:00 0 a7e01000-a7e0a000 r-xp 00000000 08:03 2240096    /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcc_s.so.1a7e0a000-a7e0b000 rw-p 00009000 08:03 2240096    /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcc_s.so.1a7e0b000-a7e2d000 r-xp 00000000 08:03 2638432    /lib/libm-2.5.soa7e2d000-a7e2e000 r--p 00021000 08:03 2638432    /lib/libm-2.5.soa7e2e000-a7e2f000 rw-p 00022000 08:03 2638432    /lib/libm-2.5.soa7e2f000-a7f01000 r-xp 00000000 08:03 2240097    /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6.0.8a7f01000-a7f04000 r--p 000d1000 08:03 2240097    /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6.0.8a7f04000-a7f06000 rw-p 000d4000 08:03 2240097    /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6.0.8a7f06000-a7f0c000 rw-p a7f06000 00:00 0 a7f2b000-a7f2d000 rw-p a7f2b000 00:00 0 a7f2d000-a7f2e000 r-xp a7f2d000 00:00 0          [vdso]a7f2e000-a7f48000 r-xp 00000000 08:03 2639003    /lib/ld-2.5.soa7f48000-a7f49000 r--p 00019000 08:03 2639003    /lib/ld-2.5.soa7f49000-a7f4a000 rw-p 0001a000 08:03 2639003    /lib/ld-2.5.soaf9db000-af9f0000 rw-p af9db000 00:00 0          [stack]

any clues ?

mono2k

Oct 3, 2007 at 8:04 AM

my 5 cents - I have similar problem under MSVC 2005, there're irregular memory corruptions/double freeing almost every second run of my application - msvc debug heap allocator reports this on exit. There was no such problem in 2.8.1. Trying to trace this problem but still no luck :-(

WitchLord

Oct 3, 2007 at 8:51 PM

kunitoki:

I haven't updated the gnuc makefile in a while, since I don't use it myself. I do however use the gcc compiler on Mac and everything works as it should. The makefile should be easy to fix though, just include all the source files.

Your second problem looks like a bug in the AngelScript compiler, it should have produced a compiler error, since you're declaring a class inside a function (ExecuteString wraps the script in a void function). I'll have to look into this problem, thanks.

mono2k:

I use memory leak testing during all my tests, so unless you've encountered a scenario that I'm not testing (like kunitoki seems to have done) I would guess you've not registered your objects correctly so that they aren't released by AngelScript as you would expect.

With 2.11.0 WIP I'm trying to improve the registration of object types and functions so that AngelScript can perform more validations on how the registration is done, and thereby catch more of the errors without having to track difficult to find stack corruptions or memory leaks.

Regards,
Andreas

WitchLord

Oct 11, 2007 at 7:02 PM

kunitoki:

I've not been able to recreate the crash you reported, could this have been because you forgot to update the header file as well?

mono2k:

Have you had any progress on discovering the cause of your memory corruptions?

kunitoki

Oct 12, 2007 at 2:47 AM

i don't know, but everything compiled correctly when i ran that test.

anyway, i've noticed that a lot of things have changed inside the library and my efforts to align my class registrations to permite the new stuff is too work for me now.
My registered classes now don't work anymore, as it seems the allocations for objects have changed.

i'll revert angeljuice back to 2.8.1 (the best version i've ever tried) or 2.9.1 until these changes are settled and documented.

mono2k

Oct 15, 2007 at 5:23 PM

Quote:
Original post by WitchLord
mono2k:

Have you had any progress on discovering the cause of your memory corruptions?

Is there any real difference between GetArgAddress & GetArgObject and between SetReturnAddress & SetReturnObject? I have a feeling this is the reason for my problem...

Deyja

Oct 18, 2007 at 5:04 PM

And I'm still using 2.7.0. :/ Doesn't matter I guess, I'd just ignore all the new features anyway.

Deyja

Oct 18, 2007 at 6:07 PM

Oh, and,

Are we going to get a truly uniform interface for setting arguments that can handle all types the same way?

Globals already have this kind of interface.

WitchLord

Oct 20, 2007 at 6:43 PM

mono2k:

Quote:

Is there any real difference between GetArgAddress & GetArgObject and between SetReturnAddress & SetReturnObject? I have a feeling this is the reason for my problem...

Yes there is. GetArgAddress and SetReturnAddress is the raw access to the pointer value, it doesn't add or release references. GetArgObject and SetReturnObject is more intelligent and will increase references of object handles, and in case of object values it will create copies of the object as necessary.

Deyja:

If you don't feel there is a need to upgrade then it's perfectly fine to continue with the version you're using.

I'm continously improving the interface to make it easier to use, currently the GetArgPointer and GetReturnPointer is the best interface if you want a uniform interface. It gives you the address of the location where the value is stored, and let's you set the value as needed. It may not be perfect yet, but let me know how I can make it better and I'll see what I can do.

Regards,
Andreas

Deyja

Oct 20, 2007 at 7:28 PM

Quote:
If you don't feel there is a need to upgrade then it's perfectly fine to continue with the version you're using.

You misconstrue. It's not that I don't need or want to, it's just that I haven't bothered.

Quote:
I'm continously improving the interface to make it easier to use, currently the GetArgPointer and GetReturnPointer is the best interface if you want a uniform interface. It gives you the address of the location where the value is stored, and let's you set the value as needed. It may not be perfect yet, but let me know how I can make it better and I'll see what I can do.

The issue, if I remember the behavior you described in another thread, is that these functions treat primitive and object types differently. In one case, they return a pointer to the value, and in the other, they return a pointer to a pointer.

WitchLord

Oct 20, 2007 at 10:00 PM

Yes, that's true. But it's only done that way because that's how AngelScript stores the values internally.

mono2k

Oct 21, 2007 at 6:17 AM

Andreas,

Quote:
Original post by WitchLord
Yes there is. GetArgAddress and SetReturnAddress is the raw access to the pointer value, it doesn't add or release references. GetArgObject and SetReturnObject is more intelligent and will increase references of object handles, and in case of object values it will create copies of the object as necessary.

And what about properties being registered like

engine->RegisterObjectType("signal_t", 0, asOBJ_REF | asOBJ_NOHANDLE);

should I use GetArgAddress/SetReturnAddress or GetArgObject/SetReturnObject to access "signal_t" type variables?

WitchLord

Oct 21, 2007 at 11:08 AM

asOBJ_REF | asOBJ_NOHANDLE means that the script engine may not hold any handles to the object type, i.e. it cannot instanciate variables of the type, nor pass it around in parameters.

This combination of flags is only useful for singletons, where a global property is registered from the application to give the script access to the singleton's methods and properties.

mono2k

Oct 22, 2007 at 6:25 AM

it is not technically true. I'm using unsafe references and I'm able to pass a reference to "asOBJ_REF | asOBJ_NOHANDLE" object in parameters.

Is this an unwanted AS behaviour?

WitchLord

Oct 23, 2007 at 8:23 PM

Hmm, that should probably not be allowed. I'll have to think about it.

mono2k

Oct 24, 2007 at 7:04 PM

it will be nice to have an easy way to register a type that should not be allowed to be constructed in the script (i.e. instanced only via RegisterGlobalProperty) but it should be allowed to pass references to an object of that type as a parameter to script functions.

WitchLord

Oct 24, 2007 at 8:13 PM

Why would you want that? If it is already available as a global property, why pass it around as a parameter?

Topic Locked

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