I experience a problem related to config groups using 2.5.0b. We 're talking about a crash. First, what I do: 1. BeginConfigGroup 2. Register a class 3. EndConfigGroup 4. Run 5. Hit reload 6. Abort and release all running contexts 7. Discard module 8. GarbageCollect(true) 9. RemoveConfigGroup -- all is fine until now -- 10. Go to 1. At this point, at the moment I try to register the class type again (in step 2), angelscript crashes inside as_string Compare(). The crash starts from as_scriptengine.cpp:725. It's where the check is done to see if the type I 'm trying to register is already registered. Specifically in "if ( objectTypes[n]->name == name )", objectTypes[n] is null (shouldn't there be a check for this?). What happens here is that when asCConfigGroup removes the config group from the engine (as_configgroup.cpp:154), it deletes and nulls out engine->objectTypes[n] but on the next types iteration (like in this case, trying to re-register the same type) it bombs because there is a null in the list. Anyway, I added a null check there and I thought that would fix it. I was dreaming, it seems ;) Next thing I know is it still crashes, but here's the backtrace for your convenience:

#0  0x00503e3e in asCDataType::IsReference (this=0xc) at source/as_datatype.h:78
#1  0x0048c7ca in PrepareSystemFunction (func=0x0, internal=0x0) at source/as_callfunc_x86.cpp:107
#2  0x00485cf5 in asCScriptEngine::PrepareEngine (this=0x3eac20) at source/as_scriptengine.cpp:1623
#3  0x0048f087 in asCModule::Build (this=0x2c224b8, out=0x57e3f0) at source/as_module.cpp:125
#4  0x0047e1e3 in asCScriptEngine::Build (this=0x3eac20, module=0x2c0e454 "World") at source/as_scriptengine.cpp:331
#5  0x0041b907 in Scripting::LoadScript (this=0x1410304, module=@0x22fb60, filename=@0x22fb70) at scripting.cpp:193

From what I can understand, there are still null values all over the place and no checks for them... Finally, adding a null check in asCScriptEngine::PrepareEngine() (as_scriptengine.cpp:1623) did the trick and it doesn't crash anymore. Anyway, I don't know if this was the intended behaviour but I guess not. WL, any insight?

I'll verify this, but it looks like you've found the fix for the bug already. [smile]

Thanks for taking the time to do a thorough investigation of the problem. This makes it so much easier for me.

Regards,
Andreas

One thing is worrying me: are all these null entries in the lists cleared at some point or do they stay there for as long as the engine is running?

Because the lack of null-checks lead me to believe that it's not allowed to have nulls there and some other part of the engine should have taken care of them...

The null values stay in the engine until the end. The idea is that the null entries in the arrays will be reused for the next registration, but I don't remember if I have implemented that yet for this part. Before the dynamic configurations were implemented null entries were not allowed.

The lack of null checks is due to lack of test scenarios. Not too many people have actually used this feature before, so you discovered some new scenarios that were not tested before.

This makes sense. Thanks for the explanation :)