Trinitycore: [3.3.5] Pooling + dynamic_spawning

[Tauriella]

Description:
The server crashes after starting

https://gist.github.com/Tauriella/7b4e94f73174fddea29e5bbd0266dacb

Branch(es):

TC rev. hash/commit:
TrinityCore rev. 3eab2d7efcc2 2018-02-27 16:18:38 +0100 (3.3.5 branch)

TDB version: TDB_full_world_335.64_2018_02_19 + all updates

Operating system: Win7

[Treeston]

What assertion message, if any, is printed to the console?

[Tauriella]

D:\TrinityCore335_SRC\TrinityCore\src\server\game\Entities\Creature\Creature.cpp
:1644 in Creature::LoadFromDB ASSERTION FAILED:
m_respawnCompatibilityMode Creature (SpawnID 151932) trying to load despite a
respawn timer in progress.

[Tauriella]

@Treeston
If you use in the woldserver.conf "BaseMapLoadAllGrids=1"
your server will crash

[Treeston]

Thanks - probably pooling not cooperating with dynamic_spawning. I will investigate (and it probably needs a re-write).

[Treeston]

Tagging commit above should prevent the assert from crashing the core temporarily, issue will remain open until pooling is properly fixed.

[jackpoz]

any update on this ?

[Ovahlord]

Nope. The crash is also not fixed since the assert is still getting triggered. But this time it is not caused by poolings but by the GameEvent manager.
https://paste2.org/akzUI3ZF

[Kittnz]

When starting event 61...

```
C:\Source\src\server\game\Entities\Creature\Creature.cpp:1607 in Creature::LoadFromDB ASSERTION FAILED:
m_respawnCompatibilityMode || sPoolMgr->IsPartOfAPool(spawnId)
Creature (SpawnID 208904) trying to load despite a respawn timer in progress.
MapID: 1 X: -706.873 Y: -5089.25 Z: 10.1878 O: 0
GUID Full: 0xf130009cf000031d Type: Creature Entry: 40176 Low: 797 Entry 40176
Name: Sen'jin Frog
IsAIEnabled: false DeathState: 0 UnitMovementFlags: 0 ExtraUnitMovementFlags: 0 Class: 1
AIName: SmartAI ScriptName: WaypointPath: 0 SpawnId: 208904

[jackpoz]

I'll change those asserts to error logs, no need to take down worldserver just for a spawn

[Treeston]

Could you please not?

Removing the assert is not a fix to a bug. Why do I have to keep saying that?

[Ovahlord]

Why do you want to crash a server because of a bug that does not really cause any further issues? It's a object with a respawn time but it gets spawned anyways so this does not sound to me like a reason to kill a server immediately.

[jackpoz]

It's a 1 year old issue marked with priority high that crashes the server, still there has been no progress so far and it will be like that for a lot of time still, that's why an assert that is supposed to be triggered when the impossible happens is not a good choice in this case.
The how to reproduce steps are clear, you can fix the issue anytime you want.

[Treeston]

The original priority high crash was addressed over a year ago in 9fc6b13. The issue remained open as a reminder that the pooling system needed adjustments to play nice with dynamic_spawning.

If gameevent logic is doing dumb things with low-level spawning methods, then fix gameevent logic. Asserts in dynamic_spawning exist for a reason. You do not want a single creature having two respawn timers, ever. Bad things happen.

1 creature = 2 respawn entries. 2 creatures = 4 respawn entries. I don't need to explain to you how exponential growth works I think.

_(I have no idea if this particular case would cause that to happen. I haven't looked at the core in a few months. All I know is that I can't guarantee what happens if you randomly ignore asserts because it's convenient to you.)_

[killradio]

In my case it is Minigob Manabonk caused crash.

To reproduce: go to Dalaran, start event 33, after Minigob disappear, go to other location, wait till event stop (30m occurrence + 5m length), go to Dalaran again and start event 33 -> crash.

[Kittnz]

Can we have a fix for this, this is a server breaking issue really :/

[jackpoz]

When starting event 61...

@Kittnz if I ".event start 61" I don't get any crash. Do I need to be somewhere in particular ?

[Kittnz]

Yes, echo isles, And dalaran when event 33 starts.

[jackpoz]

.go xyz -773.906067 -5010.133301 17.237411
.event start 61

Confirm at 50ed1bb5b3d3
50ed1bb5b3d3_worldserver.exe_[8-6_11-38-53].txt

[jackpoz]

Some refined steps:

• .go xyz -773.906067 -5010.133301 17.237411 1
• .event start 61
• /tar darkspear scout
• .damage 50000
• .event stop 61
• .event start 61

Killing the npc saves respawn time, stopping the event doesn't remove that and starting the event tries to summon a creature which still has a respawn time.

[r00ty-tc]

Ick, to properly fix this.. In new pooling it's not so bad.. Pool respawn times are just poolId of root pool. Easy to run through and delete all of those on event stop.
But, old pooling.. The event triggers a pool, but respawn times are saved for the creature spawnId..
A bit messy but possible, and will probably solve https://github.com/TrinityCore/TrinityCore/issues/21132 at the same time.

[jackpoz]

https://github.com/jackpoz/TrinityCore/commits/3.3.5-game_event_respawn removes the respawn time of creatures/gameobjects when starting/stopping an event . It doesn't handle pools.

[jackpoz]

Opened a PR https://github.com/TrinityCore/TrinityCore/pull/23391

[akrom23]

The same problem exists in instances, e.g. Onyxia's Lair, when you are using gm command to respawn the whole instance.

Steps to reproduce (Onyxia's Lair)

• Kill all mobs from trash
• Kill Onyxia
• Use .respawn on Onyxia

[jackpoz]

that's another issue about .respawn command https://github.com/TrinityCore/TrinityCore/issues/23014