Several of our users ran into the following failed assertion:

We have been able to narrow it down to a set of scripts, but unfortunately I haven't been able to reproduce it. This code is referring to the assertion here:

	// Add it as constructor
	objType->beh.constructors.PushLast(funcId);
	asASSERT(objType->beh.copyconstruct == 0);
	objType->beh.copyconstruct = funcId;
	engine->scriptFunctions[funcId]->AddRefInternal();

Which is inside of asCBuilder::AddDefaultCopyConstructor.

The scripts in question is part of the Ghosts++ plugin ( https://github.com/XertroV/tm-ghosts-plus-plus​ ), which unfortunately is rather large, so it might be hard to narrow it down.

I think I can turn off the “default copy constructor” behavior as a short term solution, but I suppose it's a bug with this relatively new feature.

Thanks for letting me know of this. Yes, it is certainly a bug related to this new feature. I will investigate it and have it fixed.

I've gone through the code in the library, and I couldn't find any situation that would trigger this assert.

I've also looked through all the scripts in Ghosts++, but didn't find anything out of the ordinary.

I'll need some more help to identify a root cause. Can you at least identify for what class in Ghosts++ the assert is triggering? Just check the objType→name when the assert triggers.

Unfortunately I have not yet been able to reproduce the assertion myself, but I'll spend some time today trying to reproduce it. (We have identified another different plugin that also fails the assertion, but it seems to happen very rarely/randomly.)

Well that was quick. I was able to reproduce it and find out that objType→name is PlayerCpInfo as defined here: https://github.com/XertroV/tm-mlfeed-race-data/blob/ff28ad688430f7b50db1687c1749365d915277cc/src/MLFeed_ExportShared.as#L169-L247​

I suppose it is happening because PlayerCpInfo is a shared class, and as such the copy constructor is being generated multiple times as the file is loaded by multiple modules?

Thanks, that is an interesting lead. I don't think it is just because it is shared, as I have those scenarios in my regression tests. But it might be a scenario where the copy constructors fails compilation (silently) and should then be removed. And then a second declaration of the shared class might attempt to compile it again. I'll try reproducing it with this.

There was indeed some issues with the default copy constructor and shared classes, which I have now fixed in revision

https://sourceforge.net/p/angelscript/code/2897/​

I still wasn't able to reproduce the assert though. But, there is a chance that it has been fixed with these last changes. I'd appreciate it if you could give the new revision a try and let me know if there is still an issue or not (don't forget to re-enable the generation of copy constructors).

We haven't heard anyone having this issue since releasing the patch on friday, so I think we're good! Thank you as always 🥰