fix(Core/Player): prevent null pointer dereference in SendLoot function

[r0m1ntik]

• Added a null check for the game object before calling ForceValuesUpdateAtIndex to avoid potential crashes when the object is not valid.
  In Player::SendLoot the condition checks !go, but then go->ForceValuesUpdateAtIndex is called without verifying that go is not NULL. If GetMap()->GetGameObject(guid) returns NULL, this causes a NULL pointer dereference.

Changes Proposed:

This PR proposes changes to:

• Core (units, players, creatures, game systems).
• Scripts (bosses, spell scripts, creature scripts).
• Database (SAI, creatures, etc).

Issues Addressed:

• Closes

SOURCE:

The changes have been validated through:

• Live research (checked on live servers, e.g Classic WotLK, Retail, etc.)
• Sniffs (remember to share them with the open source community!)
• Video evidence, knowledge databases or other public sources (e.g forums, Wowhead, etc.)
• The changes promoted by this pull request come partially or entirely from another project (cherry-pick). Cherry-picks must be committed using the proper --author tag in order to be accepted, thus crediting the original authors, unless otherwise unable to be found

Tests Performed:

This PR has been:

• Tested in-game by the author.
• Tested in-game by other community members/someone else other than the author/has been live on production servers.
• This pull request requires further testing and may have edge cases to be tested.

How to Test the Changes:

• This pull request can be tested by following the reproduction steps provided in the linked issue
• This pull request requires further testing. Provide steps to test your changes. If it requires any specific setup e.g multiple players please specify it as well.

Known Issues and TODO List:

• [ ]
• [ ]

How to Test AzerothCore PRs

When a PR is ready to be tested, it will be marked as [WAITING TO BE TESTED].

You can help by testing PRs and writing your feedback here on the PR's page on GitHub. Follow the instructions here:

http://www.azerothcore.org/wiki/How-to-test-a-PR

REMEMBER: when testing a PR that changes something generic (i.e. a part of code that handles more than one specific thing), the tester should not only check that the PR does its job (e.g. fixing spell XXX) but especially check that the PR does not cause any regression (i.e. introducing new bugs).

For example: if a PR fixes spell X by changing a part of code that handles spells X, Y, and Z, we should not only test X, but we should test Y and Z as well.

[sudlud]

i think this needs a deeper check to correct this - right before your changed part it actually enters that section for if (!go)

looks like this is there since the first commit of AC

[r0m1ntik]

i think this needs a deeper check to correct this - right before your changed part it actually enters that section for if (!go)

looks like this is there since the first commit of AC

Yes, that’s possible, the crash only started appearing after the recent changes.

Unfortunately I don’t have the full crash log anymore, but from what I kept, everything was pointing to this area:

The crash happens in Player::SendLoot (around line 8007), when loot_type = LOOT_FISHING.
go is 0x0 (the GameObject* is NULL), but ForceValuesUpdateAtIndex is still called on it.

The backtrace I had looked roughly like this:

#0  UpdateMask::SetBit (this=0x58, index=17) at UpdateMask.h:45
    → this=0x58 (invalid/corrupted pointer)

#1  Object::ForceValuesUpdateAtIndex (this=0x0, i=17) at Object.cpp:2082
    → this=0x0 (NULL pointer!)

#2  Player::SendLoot (this=0x7ffe9dd15040, guid=..., loot_type=LOOT_FISHING)
    at Player.cpp:8007
    → go = 0x0 (GameObject* was NULL)

#3  GameObject::Use (this=0x7ffecce09a00, user=0x7ffe9dd15040) at GameObject.cpp:1797
#4  WorldSession::HandleGameObjectUseOpcode at SpellHandler.cpp:344

So it does enter the if (!go) section, but later go->ForceValuesUpdateAtIndex is called without ensuring go is non-NULL, which is what seems to be causing the crash.

[Nyeriah]

Not discrediting this PR, but the way the logic is set currently looks a bit funny, as per sudlud's comment