fix(Player/SpellQueue): bandaid crashfix

[sogladev]

Changes Proposed:

This PR proposes changes to:

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

if there's an invalid spell in the queue, clear the queue and return

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.

[Nyeriah]

cc @walkline

[walkline]

From this crashlog, we see that the spell cast request has invalid values. The more interesting question is how the values became invalid.

I saw some other recent crashlogs - one and two - which make me think that something bad is happening, such as using a dangling pointer (using a deleted player) or a race condition (e.g., double parallel updates of the same map or instance).

[Grimdhex]

Agree with walkline. No real sense to have a invalid spell here. Probably a deeper issue.

@sogladev also why clearing the queue instead to ignoring it? (Simple question, I don't remember all the process of your system)

[sogladev]

Agree with walkline. No real sense to have a invalid spell here. Probably a deeper issue.

@sogladev also why clearing the queue instead to ignoring it? (Simple question, I don't remember all the process of your system)

If the front of std::deque contains invalid data then the queue behavior is undefined. So it's best to clear the entire thing than trying to consider the next element to be valid.

I also question when std::deque contains invalid data that the pointer to the next element is also invalid, pointing to undefined memory. Now, I'm not sure what happens if .clear() is called 😆