Issues appearing on high uptime

[Auntie Mangos]

2) Instance binding IDs for players go crazy

At some point the instance id saving system doesn't really work anymore. The reset time in the /raidinfo window simply doesn't show up anymore and .instance listbinds shows that the ID of the instance remains until year 2038.

On the running server my test char got an ID for 2038 to reset. When i started that same db on my local mangos the ID was placed to 2nd Oct 6:00 so i believe it is not a db issue. (The timestamp in instance_reset is fine too)

Is someone experiencing similar issues?

Also noticed those SQL errors

SQL: INSERT INTO group_instance SELECT guid, instance, permanent FROM character_instance WHERE guid = '1217639'
SQL ERROR: Duplicate entry '1217639-1451' for key 1

Point 2 confirmed

http://getmangos.eu/community/viewtopic.php?id=9793

(might give it a bump)

[leak]

Hey guys,

i'm encountering a few troubles that only seem to appear on high uptime. In my case i consider high uptime 50h+ with 900ppl online.

Currently running pretty much the lastest 0.12 branch rev (923e00df) with sd2 1410 (with backport patch to 0.12). I'm also running full vmaps for a while now without lags.

Issues:

1) Memory leaks caused by vmaps

I observed a constant memory growth when mangos is running for longer periods. At some point mangos consumed about 8GB of the servers memory. I never noticed when i only had partial vmaps enabled, so i believe there is some issue and this issue is aggravated by vmaps on world contintens.

If i'm not all wrong vmaps also still cause endless loops which get the server killed. I'm running a patch to prevent that, maybe those memleaks are also related to those endless loops.

It would be nice to know if someone is still working on vmaps.

2) Instance binding IDs for players go crazy

At some point the instance id saving system doesn't really work anymore. The reset time in the /raidinfo window simply doesn't show up anymore and .instance listbinds shows that the ID of the instance remains until year 2038.

On the running server my test char got an ID for 2038 to reset. When i started that same db on my local mangos the ID was placed to 2nd Oct 6:00 so i believe it is not a db issue. (The timestamp in instance_reset is fine too)

Is someone experiencing similar issues?

3) Lootable gameobjects become inaccessible

After a while GOs like mining nodes or herbs always show up empty and the problem here is they stay that way.

First i thought it was some sort of exploit and i actually found something. (Roughly: If two people trying to open a GO at the same time it becomes completely inaccessible afterwards, even for GM .respawn, i can give more detail on this if required). However, arrai came up with a fix (here) but he said himself that this wasn't a proper way and there is most likely a bigger problem in the loot system.

I've been running this patch for a while now but it looks like he was right and there is a bigger issue because mining nodes, etc. still become unlootable on high mangos uptime.

Thanks for reading.

[FunkyBit]

I can confirm point 2) and 3).

The loot problem with gameobjects is almost 1,5 years old...

We will try out the patch also!

[FragFrog]

Our testserver once had an uptime of 140 days (not kidding, got a screenie of it even - almost no users on though). Memory useage stayed very much the same - even with full vmaps. So for option 1, it might be, but I would guess it's related to player interaction. Perhaps grid unloading is of some influence?

Points 2 and 3 are confirmed here as well. For point 2, I notice a lot of SQL errors for the instance primary key constraint. I guess changing the update into a replace would fix it, but since I have no idea how this will affect game mechanics I have so far not bothered to do so.

[leak]

I'm running the server with grid unload 0 but no idea how that affects vmaps.

Also noticed those SQL errors

SQL: INSERT INTO group_instance SELECT guid, instance, permanent FROM character_instance WHERE guid = '1217639'
SQL ERROR: Duplicate entry '1217639-1451' for key 1

[crashuncle]

I can confirm all points which got described by Leak, the memory usage is increasing with Vmaps after a few days uptime. For me it gets to 5GB after 2-3 days~ Also instances make problems like mixed up cooldowns and the gameobject bug existed already in WoWD. I like to call it "realistic resource bug"

[Lascax]

I can confirm point 1 & 2 in 0.12.

[LordJZ]

I can confirm 3)

Try this fix for 2) http://dev.trinitycore.org/trinitycore2/changeset/853430b4f96d/

[leak]

LordJZ are you sure about this fix?

Too bad the page is currently not reachable. Any other source for that commit?

[leak]

I created a .patch for 2) from that trinity commit and gonna give that a shot now.

http://pastebin.com/f2cc951fa

The "REPLACE INTO" hunks are most likely no proper solution because the fact that there is a db entry left and the core itself says there is nothing loaded yet just doesn't match up.

I wish someone could take a closer look at this.

[ANTOMA]

Hey guys,

Issues:

1) Memory leaks caused by vmaps

I think issue with vmap solved in commit

PS am not a player but about path from trinity - as say testers reset always after 24hrs

[leak]

I can't confirm that. Today for example our ZA ID went out and the next one is in 3 days again.

Can anyone else share the results of that or a similar patch?

[zhenya``]

3) Lootable gameobjects become inaccessible

After a while GOs like mining nodes or herbs always show up empty and the problem here is they stay that way.

First i thought it was some sort of exploit and i actually found something. (Roughly: If two people trying to open a GO at the same time it becomes completely inaccessible afterwards, even for GM .respawn, i can give more detail on this if required). However, arrai came up with a fix (here) but he said himself that this wasn't a proper way and there is most likely a bigger problem in the loot system.

I've been running this patch for a while now but it looks like he was right and there is a bigger issue because mining nodes, etc. still become unlootable on high mangos uptime.

in GameObject::Update

place this

       case GO_ACTIVATED:
       {
           switch(GetGoType())
           {
               case GAMEOBJECT_TYPE_DOOR:
               case GAMEOBJECT_TYPE_BUTTON:
                   if (GetGOInfo()->GetAutoCloseTime() && (m_cooldownTime < time(NULL)))
                       ResetDoorOrButton();
                   break;
_
               case GAMEOBJECT_TYPE_CHEST:
                   if (!isSpawned())
                       SetLootState(GO_JUST_DEACTIVATED);
_
                   break;
               default: break;
           }
           break;
       }

[leak]

I've been running the patch for 2) (see above) for a while now and it seems that it fixes the problem at least for instances likes Zul'Aman and Zul'Gurub, yet for heroic instances it got worse. Now heroics don't even reset after a server restart. In the table instance_reset those heroic instances have all the same strange resettime of 5549918400 which is hardly a timestamp for this century..

Also in the instance table there are plenty of entries that have resettime 0 (instance id 556 AuchindounDemon with difficulty 1 for example, i suppose that's heroic?). I wonder what that is all about.

Something about the whole instance ID system is seriously flawed. I don't run an 3.x server so far, can anyone give an impression on how the behavior with instance resetting is there?

@zhenya

Do you have any source for this patch?

[leak]

Today ID reset went fine for all instances, at least ingame that is.

Checking the DB i found 3 maps having 5551387200 as reset time again, this time Zul'Gurub, Zul'Aman and AQ20 were affected. Yet ingame all instance reset times were fine, so the issue would only have appeared on a server crash when the false db values will be reloaded.

I still have no idea why ingame cycle works fine and db gets filled with wrong values.

[DasBlub]

Today ID reset went fine for all instances, at least ingame that is.

Checking the DB i found 3 maps having 5551387200 as reset time again, this time Zul'Gurub, Zul'Aman and AQ20 were affected. Yet ingame all instance reset times were fine, so the issue would only have appeared on a server crash when the false db values will be reloaded.

I still have no idea why ingame cycle works fine and db gets filled with wrong values.

maybe there's an error in the insert-query and it doesn't take the correct number ? (i don't have the sources here, so i can't check it myself)

[Betaman2k]

core 8865

confirmed number 2