You did not read my ticket correctly or do not understand it.

when compiling with the Debug CRT, it *does not zero the memory*, it sets it to different debug values depending on the type/method of allocation (see the link I provided (http://stackoverflow.com/questions/370195/when-and-why-will-an-os-initialise-memory-to-0xcd-0xdd-etc-on-malloc-free-new). Additionally, it will fill buffers for different string and memory copy/allocation functions for debug purposes.

This means you *cannot run extensions compiled against the Debug CRT*, only built against the release CRT. It's not world ending, but its annoying when working on complex extensions. That means, if you do something to the affect of:

ACE_VD_EXPORT void __stdcall RVExtension(char *output, int outputSize, const char *function) {

sprintf_s(output, outputSize, "My Balls");

}

The debug CRT writes:
output = My Balls 0x00 0xFE 0xFE 0xFE 0xFE

Thus triggering this warning. Which has nothing to do with a buffer overflow, its just that the 2nd to last byte they provided me is not null.

This can be worked around in the extension by setting the 2nd-to-last output byte to 0x00 no matter what.

Ideally though, this should be appropriately handled with a correct guard byte after the buffer - not a guard byte inside the buffer sent to the function.

This does not occur in release builds because ArmA3 zero'es the buffer prior to passing it to you; its specifically your extensions debug flag which is re-writing the buffer.

Run the below provided code with more than 15 clients connected to a dedicated server:

if(isServer) then {
repro001_delay = diag_tickTime + 10;

repro001_function = {

		if(diag_tickTime > repro001_delay) then {
			_group1 = createGroup west;
			"B_APC_Wheeled_01_cannon_F" createUnit [[0,0,0], _group1, ""];
			[repro001_handle, "onEachFrame"] call BIS_fnc_removeStackedEventHandler;
		};

};

repro001_handle = ["repro001", "onEachFrame", repro001_function] call BIS_fnc_addStackedEventHandler;
};

No repro on latest dev.

I've narrowed this down to executing addCuratorEditableObjects when an object is null but not completely deleted yet. This happens when players become out of sync and a null object persists on a client which does not exist on the server.

I cannot reliable reproduce this, but it does reproduce sometimes with the attached mission.

Further testing: It is definitely when an invalid object exists that this will cause a crash. Basic testing is to play a large MP game until you are receiving "Object not found" errors, then run the command on that object. It will crash.

Assuming a null dereference in addCuratorEditableObjects on an invalid object.

This is still appearing broken with some units. Specifically, some modded units inherit from default BI Pilot models which cause all inherited models to also be broken with these selections.

As nou said, this is specifically due to the BLUFOR pilot model; but then is somehow an inherited break across other units as well. Is this a skeleton issue, or perhaps a unit config issue?

We are beginning to suspect this is a unit configuration issue regarding incorrectly aligned hiddenSelection configurations - or model types hardcoded into the engine.

The issue is becoming to appear systemic, but we are not sure what is causing the issue in vanilla nor modded units; but it appears to occur across the board with these specific selections, only on specific units.

See here in the ACE tracker, how the issue is appearing is non-vanilla units as well: https://github.com/acemod/ACE3/issues/1346

[7:29:15 AM] jaynus: basically, its broken on a few vanilla units right? But we are finding its also broken on some mod units
[7:29:19 AM] jaynus: So there is some relationship between the vanilla units and the modded units that's causing the issue. So I thought it might help them hunt it down.

This is awesome! Will get it tested when it hits dev tomorrow!