fwEvent<>::callback destructor can cause stack overflows

[alexguirre]

What happened?

The callback struct forms a linked list with pointers to the next callback:

fivem/code/client/shared/EventCore.h

Lines 254 to 266 in 5529812

	struct callback
	{
	TFunc function;
	std::unique_ptr<callback> next = nullptr;
	int order = 0;
	size_t cookie = -1;
	callback(TFunc func)
	: function(func)
	{
	}
	};

Its destructor gets compiled to something like this:

void __fastcall callback_dtor(__int64 a1)
{
  __int64 v1; // rbx
  __int64 v2; // rdx
  __int64 v3; // rcx

  v1 = *(_QWORD *)a1;
  if ( *(_QWORD *)a1 )
  {
    callback_dtor(v1 + 64);
    v3 = *(_QWORD *)(v1 + 56);
    if ( v3 )
    {
      LOBYTE(v2) = v3 != v1;
      (*(void (__fastcall **)(__int64, __int64))(*(_QWORD *)v3 + 32i64))(v3, v2);
      *(_QWORD *)(v1 + 56) = 0i64;
    }
    j_j_free((void *)v1);
  }
}

Notice the recursive call to callback_dtor. When the callbacks list grows large, it can end up causing a stack overflow crash.

Expected result

Don't cause a stack overflow independent of the callbacks list size

Reproduction steps

One possible way to trigger this crash from a resource is with ADD_STATE_BAG_CHANGE_HANDLER. Adding lots of handlers and reloading the resource, causes the crash when the underlying StateBagComponent::OnStateBagChange event deletes its callbacks.

for i=1,40000 do
    AddStateBagChangeHandler(nil, nil, function(bagName, key, value, _unused, replicated)
        print('state bag changed' .. bagName .. ' ' .. key .. ' ' .. value)
    end)
end

Unsure if there are other easy ways to trigger it. In theory, anything that adds fwEvent callbacks dynamically could eventually crash.

Importancy

Crash

Area(s)

FiveM, RedM, FXServer

Specific version(s)

Any

Additional information

Got a crash dump from a user. In this case, it crashed when reloading resources and the stack has like 30K stack frames of the callback destructor, so somehow some event ended up with 30K callbacks. Possibly the stage bag change handlers, but I don't know what his resources are doing exactly.

CfxCrashDump_2024_06_07_14_03_59.zip

[gottfriedleibniz]

Thanks for the report!