(AS 2.10.0 rev 199) asCScriptEngine::RegisterGlobalProperty:

...
	asCBuilder bld(this, 0);
	if( (r = bld.VerifyProperty(0, declaration, name, type)) < 0 )

later in a nested call to asCBuilder::GetGlobalProperty:

...
	for( n = 0; n < props->GetLength(); ++n )
		if( (*props)[n] && (*props)[n]->name == prop )
		{
			// Find the config group for the global property
			asCConfigGroup *group = engine->FindConfigGroupForGlobalVar((*props)[n]->index);
			if( !group || group->HasModuleAccess(module->name.AddressOf()) )
				return (*props)[n];
		}

and we have access violation since module == 0 due to "asCBuilder bld(this, 0)" therefore module->name is undefined. Is this a bug?

Sure is. Assert failures and access violations within the library are always bugs in the library. Regardless of how the library is used by the application should it ever perform access violations or fail on asserts. If the library is used incorrectly it should return proper error codes to the application.

I'll look into this. Thanks for the report.

I'm running my game through compuware's boundschecker and everything within AS looks fine. I have just one question, it is not a bug since my code works, I simply don't understand the logic behind:

as_context.cpp:2103

	case BC_STOREOBJ:		// Move the object pointer from the object register to the object variable		*(size_t*)(l_fp - SWORDARG0(l_bc)) = size_t(objectRegister);		objectRegister = 0;		l_bc++;		break;

there is no actual obj ptr copy from obj register to obj variable, is it already copied at this point?
I'm asking because boundschecker always warn "memory leaked" on objectRegister = 0 .

[Edited by - mono2k on September 19, 2007 6:05:47 AM]

*(size_t*)(l_fp - SWORDARG0(l_bc)) = size_t(objectRegister);

This line copies the pointer in objectRegister to a location on the AngelScript stack (temporary variable).

I guess boundschecker doesn't understand what's going on on that line, thus thinks the memory is leaked.

Oops, too many coding, I've read sizeof instead size_t...

I've fixed the bug you reported now. You can get the fix from the SVN (revision 200).

Thanks!

I've used 2.8.0a before the trunk, and it was possible to have two global properties named identically in different config groups. It looks like this behaviour has been changed, am I right?

It shouldn't have been possible before either, that must only have been something that I had overlooked.

Although you can use configuration groups to expose different parts to different modules they are still in the same namespace, thus more than one property with the same name would cause a conflict. It didn't cause a problem for you because you didn't change the module's access to the groups.

In a future version I'll add support for namespaces though, which seems to be what you need.

Regards,
Andreas