CNetGamePlayer::GetGamerInfo returns nullptr, causing crashes

Immer wieder Fehler
image

image

CfxCrashDump_2022_05_21_17_37_19.zip (2.4 MB)

Recently we pushed a potential fix, try it out on canary. It may resolve this issue potentially.

Please report if you get new crashes during gameplay. Also report if you see any CNetGamePlayer crash again.

DO NOTE THE POTENTIAL FIX IS ONLY ON CANARY.

1 Like

CfxCrashDump_2022_05_22_05_26_36.zip (2.3 MB)

CfxCrashDump_2022_05_22_06_58_35.zip (2.4 MB)

CfxCrashDump_2022_05_22_21_15_19.zip (2.1 MB)

CfxCrashDump_2022_05_23_03_36_50.zip (2.3 MB)

image

65c03f3a-9387-4461-9700-43c34156b1dd.dmp (10.3 MB)

[Window Title]
RedM

[Main Instruction]
CNetGamePlayer::GetGamerInfo returned nullptr, this is a fatal error.

[Content]
Physical player index: 31
Active player index: 255
Player address: 2314e753ac0

Please report this issue, together with the information from ‘Save information’ down below on
https://forum.cfx.re/t/cnetgameplayer-getgamerinfo-returns-nullptr-causing-crashes

[^] Hide details [Save information] [Close]

[Expanded Information]
Report ID: si-083290ae8f8244f2af27e56a26395f44
CfxCrashDump_2022_05_24_11_21_21.zip (2.4 MB)

CfxCrashDump_2022_05_24_21_57_44.zip (2.5 MB)

Found a fairly consistent way to replicate GetGamerInfo crashes (not necessarily this precise nullptr error, but the same function and a new crash from the Canary changes: pip-six-sad). It always occurs while the player owner of a net object is culled by the player observing the net object with slot ID 31 as the owner (normal) since the original player owner is out of scope. It’s a bit of a pain, but I’ve been able to trigger several crashes just spending a little bit of time following these steps repeatedly using two local clients (1436, cl2) with barebones resources, spawned into Valentine (default) with player 3 model, and setting the player culling radius low:

Join with client 1, which will inevitably become the world grid owner for that area. Join with client 2. If not already set on playerJoining, set player culling radius of each player to something small like 5.0 or even 10.0. Player 1 will still see all entities, including player 2 (assuming since it’s the world grid owner). Player 2 will only see player 1 or its owned entities while within the culling radius set. Now the key to crashing: with player 2, pretty much just run through Valentine causing networked objects owned by player 1 to come into scope. Doors especially seem to lag and trip things up and usually I’m passing through a doorway when I crash. The Valentine Saloon front swinging doors are very easy to trigger it. It’s rudimentary, but I crash pretty easily and quickly when setting the player culling radius very small, even as low as 1.0 if you want to trigger it quickly.

Using the following server code to set player culling radius for all players (on playerJoining event or manually with the command):

AddEventHandler("playerJoining", function(source, oldId)
    local radius = 5.0
    SetPlayerCullingRadius(source, radius)
end)

RegisterCommand("scopesetall", function(source, args, rawCommand)
    if args[1] then
        local radius = tonumber(args[1])
        local playerIndices = GetNumPlayerIndices()
        for playerIndex = playerIndices, 1, -1 do
            local player = GetPlayerFromIndex(playerIndex-1)
            print('setting player ' .. tostring(player) .. ' culling radius to: ' .. tostring(radius))
            SetPlayerCullingRadius(player, radius)
        end
    end
end)

Still looking into what may be going on exactly. I know that the player culling radius used is extreme, but it seems to aggravate the issue or another issue with the same function at least. I’d never use such low radiuses normally. Maybe it won’t lead to anything, but figured I’d note it at least.



CfxCrashDump_2022_05_26_02_26_03-Release.zip (2.2 MB)
CfxCrashDump_2022_05_26_02_03_47-Canary.zip (2.1 MB)
CfxCrashDump_2022_05_26_01_26_24-Release-GetGamerInfo.zip (2.1 MB)

CfxCrashDump_2022_05_26_05_37_16.zip (2.2 MB)

CfxCrashDump_2022_05_29_11_00_57.zip (2.4 MB)