[AC] [Bug/Crash] [Core] Crashes when (un)loading maps / bgs

[Ramvaris]

DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

• I understand that my issue may get closed without notice if I intentionally remove or skip any mandatory* field

Current behaviour

Since I accidentally closed my last ticket, because I am really bad with GitHub - here is my problem again - but this time a bit more structured and right away with a crash log.

My findings / theories summarized by an AI since I got this all a bit to cluttered.

---

Summary of the Bug:
The server is experiencing critical stability issues due to a Use-After-Free memory corruption bug. The bug is triggered during map/grid unload events (e.g., leaving a Battleground, switching characters). A debug build has confirmed a dangling pointer is being used during the map cleanup process, causing a fatal ACCESS_VIOLATION.

Symptoms:
The bug manifests differently depending on the build configuration:

Release Build: Intermittent BREAKPOINT crash in libmysql.dll after leaving a BG, or a World Thread hang crash when the server is left idle.

Debug Build: A hard crash with ACCESS_VIOLATION, preceded by heap assertions like _CrtIsValidHeapPointer and vector subscript out of range.

Steps to Reproduce:
The issue is intermittent and appears to be cumulative, requiring an invalid memory state to be reached.

Engage in activity that loads and then unloads map instances or grids.

Reliable trigger: Play and leave several Battlegrounds. The crash will eventually occur upon leaving one of the instances.

Other triggers: Switching between characters or logging out of the game.

The common, unifying factor for all crashes is a map/grid unloading event.

Root Cause Analysis:
A Debug build has definitively identified the root cause as a Use-After-Free memory error in the C++ code. The proof is as follows:

Dangling Pointer Confirmed: At the moment of the crash in a debug build, the RAX register contains the value 0xFEFEFEFEFEFEFEFE. This is the specific sentinel value used by the MSVC debug heap to mark freed memory, which is undeniable proof that a dangling pointer is being used.

Crash Location: The call stack consistently shows the crash occurs during the map cleanup process, within functions like MapInstanced::DestroyInstance or Map::UnloadGrid.

Immediate Trigger: The use of the dangling pointer leads to reading a garbage value from the freed memory. This garbage value is then used as an invalid index for an std::vector, causing a vector subscript out of range assertion which results in the final ACCESS_VIOLATION.

Two crash logs:
c6ab8cefae4d_worldserver.exe_[5-8_9-57-20].txt
c6ab8cefae4d_worldserver.exe_[5-8_10-4-45].txt

Expected behaviour

No crashes when joining / leaving BGs or by Bots despawning and unloading maps.

Crashlog

No response

Steps to reproduce the problem

a) Join and Leave a BG. Sometimes multiple times until it happens
or
b) Switch between characters

TrinityCore or AzerothCore

AzerothCore

Core rev. hash/commit

AzerothCore rev. c6ab8cefae4d 2025-08-03 15:38:01 +0700 (npcbots_3.3.5 branch) (Win64, Debug, Static) (worldserver-daemon)

Operating system

Win 11 Pro

[trickerer]

Try after trickerer/AzerothCore-wotlk-with-NPCBots@730c617

[Ramvaris]

Tried it. Multiple BG join / leaves didn't crash the server. Switching to multiple characters also worked just fine. So that bug seems to be gone. If the other 'no one logged in but server crashes after a while' bug was also by a bot swapping a map (or unloading) then I guess that is gone too. So... yeah. Seems to be gone! I will play for some hours and close the ticket if nothing happens anymore. Nice work there, buddy.

[trickerer]

Do not close the ticket please.
The ticket must stay open until the fix is added to the patch.

[Ramvaris]

Okey. The problem CHANGED but is not gone. Now it crashes without console output or crash dump. I tried different things but it seems that I can't really locate the culprit. My wife and I are playing on our server here and we tried to load both an alterac - that caused a crash. On another time I swapped between chars and bgs - worked fine - then I went to Uldaman (Level 36 character) and suddenly while shooting some Troggs the server was gone again. I started it with Powershell to see if there was any sort of... output before the crash. But nothing.

As you can see just some warnings about equipment (but they are always there in the debug mode) and then - shortly after starting the alterac through my wife - crash. I couldn't even join mine.

[Ramvaris]

No crashes anymore until now. It could be that the AHBot Mod made some crazy stuff beside the map loading error. I am playing around with it now - it also caused micro stutters on Cycle Updates which didn't happen before - that's why I think it may be a 'co-effect' and not on your side. I will add another answer if I crash again now that I fixed this.

[Ramvaris]

Okey. 1 hour without crash. Seems to be fine. I let the ticket open until the next patch cycle. Lets hope its fixed. Thanks again for the swift fix.

[Ramvaris]

Just a small update:
Still no crash - in hours of playing with 2 players and 120 active bots around the world. So it really seems to be fixed.

[Ramvaris]

Another Update. I had some crashes today again. I re-compiled a debug version to see what happens - since there were no crash logs at all - but with max. log-depth and Debug-Version I got this:

---

ASSERTION FAILED

Location: E:\Games\WoWPrivateNew\source\AzerothCore-wotlk-with-NPCBots\src\server\game\Entities\Object\Object.h:369
Function: GridObject::RemoveFromGrid
Condition: IsInGrid()

---

So it seems there may be some leftover things to fix?

Version: AzerothCore rev. 730c61714dda 2025-08-05 19:32:50 +0700 (npcbots_3.3.5 branch) (Win64, Debug, Static) (worldserver-daemon)

[Ramvaris]

Addition: Crashes are very often now - always with the same error. Nearly any time I start the worldserver up. Some times I have ~1 minute before it happens. It worked fine the last days - and I didn't change anything from the last few hours of running perfectly fine. Since it is a 'RemoveFromGrid' error I just assume that it is connected from the removal of bots when they despawn / leave a map or whatever? So to this bug. Maybe I'm totally wrong here. Don't know the code well enough.

[Ramvaris]

Another addition (sorry for the wall of text, but maybe it helps): For a while I thought the problem is one specific char as it only crashed when doing some stuff with it - usually around 0-5 minutes. Other chars didn't seem to cause the problem. But after a while the 'problem character' didn't cause crashes either. So maybe it was just by chance since it is my main char and I usually log in with it as first character.

For the background: I have NO personal bots active (they just are on bgs and to make the word more lively) so nothing in the NPCBot DB character wise - checked that. But the crashes vanished after I used log-level 5 to search for the culprit further. So for now it seems relatively stable again. But the problem seem to still be there (in specific cases) and the Grid-Unload / -Remove.

[Ramvaris]

Last Addition: The crashes continue. Even a trace-level log didn't show anything more useful. I attached one - at least the last seconds - but the server just gave up. Same goes for a debug level log i did before. Also attached. I stop for today. It's to taxing right now. If it is from the changes - it may help you. I also noticed that Eluna as mod changed some functions because some Grid Update from the AzerothCore Master... I had to change the functions back because we lag a bit behind here. Maybe that's connected who knows.

Debug.txt

Trace1.txt

[Ramvaris]

Okey. I was blind. Sorted the folder wrongly. There ARE Crash Reports. I attach some of them. It seems to really be connected to the Bots. It's always the same thing but just to have a reference I added more than one.

730c61714dda+worldserver.exe[10-8_23-11-41].txt
730c61714dda+worldserver.exe[10-8_23-1-5].txt
730c61714dda+worldserver.exe[10-8_22-42-45].txt
730c61714dda+worldserver.exe[10-8_22-34-38].txt
730c61714dda+worldserver.exe[10-8_22-30-31].txt
730c61714dda+worldserver.exe[10-8_22-19-17].txt
730c61714dda+worldserver.exe[10-8_22-6-14].txt

[Ramvaris]

After getting really annoyed I started to work around in the core - and the following list of safeguards did at least prevent a crash now for a full hour (server still running):

In the GridNotifiers.h:

void operator()(Creature* u)
{
    // Prevents Chain Reactions to mobs - causing a cascade error
    if (u->IsInCombat())
        return;
        // Rest of the Code

In the Map.cpp

template<class T>
void Map::RemoveFromMap(T* obj, bool remove)
{
    // Previous Code
    // This should prevent double removals and therefore crashes under heavy-load
    if (!obj->IsInGrid())
        return;
    // Rest of the Code

I added another fix in the SmartScript.cpp, since the first two didn't prevent all crashes but at least the object.h one:

1 of 2 - After the #includes:

thread_local bool g_smartScriptProcessing = false;

struct SmartScriptProcessorGuard
{
    SmartScriptProcessorGuard() { g_smartScriptProcessing = true; }
    ~SmartScriptProcessorGuard() { g_smartScriptProcessing = false; }
};

2 of 2 - And then in the SmartScript::ProcessEvent-Function later on, right after the begin ( { ):

    if (g_smartScriptProcessing)
        return;

    SmartScriptProcessorGuard guard;

This last patch also sped up the smartscripts noticeably. I think it MAY be because of the bots using smartscripts and running so many? I also opened a ticket at the original azerothcore git since I am NOT sure if this is a general problem with to much scripts at the same time. I will observe the problem and give a feedback in the next days if everything is fine or immediately when it crashes again.

[Ramvaris]

I let the server run and played on it. Yesterday for 4 hours. Today for 6 hours and still going. No crash happened. The SmartAI Fix really seemed to have stopped the stack overflow problem completly while the map.cpp fix removed the objects.h crash. I would also still say that many SmartEvents work WAY faster. Like the release of the orcs in the Blood Furnance. Or mob reactions at all. I don't know why.