SourceMod SDK: introduction into Valve memory system

[Wend4r]

These changes to the overload of memory operators are necessary for components that include HL2SDK and subsequently static linking with the tier1! It was originally written to use the Valve memory system from tier0, so that through it there was an abstract opportunity to profile working with memory (g_pMemAlloc) to find leaks.

AMTL is not overloaded - it has a separate working environment with memory.

[asherkin]

Thank you for the PR, but this is going to need a lot more description and rationale to consider merging.

[Wend4r]

I really don't like that in my extension with the tier1 used, memory can first be allocated from operator new -> malloc, and then closed in IMemAlloc::Free

And operator delete is used for allocated memory from tier1 which is used IMemAlloc inside

[Wend4r]

If I include separately tier0/memoverride.cpp , then there will be a conflict of operator overloads at the linking stage with

sourcemod/public/smsdk_ext.cpp

Lines 483 to 501 in 5611ec5

	void *operator new(size_t size)
	{
	return malloc(size);
	}
	void *operator new[](size_t size)
	{
	return malloc(size);
	}
	void operator delete(void *ptr)
	{
	free(ptr);
	}
	void operator delete[](void * ptr)
	{
	free(ptr);
	}

so I decided to embed g_pMemAlloc overload in the SourceMod SDK for components using the HL2SDK with tier1

[asherkin]

I do think this might end up a little painful across games, there was a bunch of Source games that had memoveride disabled on Linux builds, so a lot of testing will be required (and CI isn't going to validate anything here).

If your root issue is just cross-crt allocation around CUtlVector, you might be interested in a solution similar to #1165.

Other than seeming like a large-ish linkage change here (which we've done worse of recently, and paid the support price), I'm not really for or against it, but would like the thoughts of @psychonic who knows the engine much better than I.

[Wend4r]

I do think this might end up a little painful across games, there was a bunch of Source games that had memoveride disabled on Linux builds, so a lot of testing will be required (and CI isn't going to validate anything here).

Games that do not support MemAlloc overloading/override will be ignored

sourcemod/AMBuildScript

Lines 623 to 625 in 4e3df76

	if sdk.name in ['css', 'hl2dm', 'dods', 'sdk2013', 'bms', 'tf2', 'l4d', 'nucleardawn', 'l4d2']:
	if compiler.target.platform in ['linux', 'mac']:
	compiler.defines += ['NO_HOOK_MALLOC', 'NO_MALLOC_OVERRIDE']

sourcemod/public/sample_ext/AMBuildScript

Lines 348 to 350 in 62cb6a0

	if sdk.name in ['css', 'hl2dm', 'dods', 'sdk2013', 'bms', 'tf2', 'l4d', 'nucleardawn', 'l4d2']:
	if builder.target_platform in ['linux', 'mac']:
	compiler.defines += ['NO_HOOK_MALLOC', 'NO_MALLOC_OVERRIDE']

sourcemod/public/sample_ext_nosdk/AMBuildScript

Line 244 in 62cb6a0

compiler.defines += ['META_NO_HL2SDK']

I built and looked, they use malloc/free

[Wend4r]

Another motivation to do this PR was what I saw in Valve binaries that they use MemAlloc overloading/override for binaries using tier1 (in server.so, engine.so and etc.)

[psychonic]

but would like the thoughts of @psychonic who knows the engine much better than I.

I think this would probably be a net positive change, but the blast radius is huge. We need better ways to test these kinds of changes across all or most supported engines (or someone needs to test this one with brute force) before we can take this change.