cba_common_PFHhandles, Error Max array size would be reached.

[commy2]

Error Max array size would be reached. Current size: 999999, wanted size: 1000000.

Another one of these:
https://forums.bistudio.com/topic/168277-cba-community-base-addons-arma-3/?p=2962614

Apparently happens only after long sessions. Might be caused by misuse of CBA_fnc_addPerFrameHandler (could also be something in ACE, or some different addon entirely)

I think this needs some debuging messages when the 1kk array size is reached to figure out what the cause is.

Related:

_publicHandle = cba_common_PFHhandles pushback _handle;
_data = [_func, _delay>
 7:10:18   Error position: <pushback _handle;
_data = [_func, _delay>
 7:10:18   Error Max array size would be reached. Current size: 999999, wanted size: 1000000.
 7:10:18 File x\cba\addons\common\fnc_addPerFrameHandler.sqf, line 16
 7:10:18 Error in expression <

No idea if related, but this error was spammed before PFH started:

if (alive btr_1) then {
btr_1 setpos [ getmarkerPo>
 3:57:43   Error position: <btr_1) then {
btr_1 setpos [ getmarkerPo>
 3:57:43   Error Undefined variable in expression: btr_1
 3:57:43 File mpmissions\__cur_mp.Woodland_ACR\mission\vehicle_fix.sqf, line 3
 6:44:23 Error in expression <e_fix.sqf"
while {true} do {

[jokoho48]

i think this "bug" is not fixable without changing the system completly

[PabstMirror]

I think it should be fixed by the people calling the code, adding PFEH each frame should not be happening.

otherwise I see two options:

• GVAR(PFHhandles) would become an array of arrays. E.G. 0-100,000 in first array, 0-200,000 in 2nd array, and so on. Downside is increased complexity, and at some point we're going still going to have floating point precision problem of huge handle numbers.
• Reuse old handles. biggest problem is you can get unexpected results. It breaks the promise we give that handles will always be unique. It would only kick in after there is a problem so it's more about keeping the game working. Made a quick (untested) prototype here: cf8babf

[commy2]

My first step would simply adding debug into the RPT to see which function(s) are added so much. Both cases here used ACE, so maybe we can fix it ourselves.

[Killswitch00]

pushBack will return a negative array index (-1) when you add the millionth element to an array. In this case, it happens in CBA_fnc_addPerFrameHandler and we then put that result (_publicHandle) into an array that is then added to the end of cba_common_perFrameHandlerArray.

Later, when CBA_fnc_removePerFrameHandler is called and that negative array index is used in the expression GVAR(PFHhandles) set [_publicH, _newHandle] a followup error is logged.
(_publicH will be -1 here)

Possible fixes and workarounds:

• Put a check in CBA_fnc_addPerFrameHandler to avoid adding "element 1M". (Return -1 indicating failure to the caller)
• Add a -1 safety check in CBA_fnc_removePerFrameHandler
• Do not add a new PF handler if CBA_fnc_addPerFrameHandler is called again with a set of parameters (function, delay, params) that was used once before. (Why would two or more PFH's with the same function, delay and input parameters be needed?)

However, as mentioned, the core issue is why is CBA_fnc_addPerFrameHandler being called one million times? In the end, it may be that some mission or addon is abusing the frame handlers, either due to mistakes/bugs or a misunderstanding of them.

[commy2]

Related issue: #230

[commy2]

In the current 1.55 dev there seems to be a different array size limit:

_a = []; _a resize 1E6; _a pushBack 1
-> 1e+006

_a = []; _a resize 1E7; _a pushBack 1
-> 0

They seem to overflow instead:

_a = []; _a resize (1E7+1); _a pushBack 1; _a
-> [1]

[commy2]

I think this can be closed. I'm pretty sure now, that this happened, because BI was tinkering with array size limits. There seem to be no more reports of this.