leak

On a server with a few hundred players there are some that exceed the maximum client response delay (90sec default) even though they still seem to be connected and their latency is fine. The number of people failing the max response delay is much bigger than those who fail actual checks, that seems a bit odd. Anyone an idea what that is all about?

Can't really do any further debugging - not a Mac owner myself either.

Any new on OS X support? I tried your implementation TOM_RUS and currently it crashes the client after loading the module (Module_0DBBF209A27B1E279A9FEC5C168A15F7_Data). **edit Client crashes with Improper header received: [ CE FA ED FE 07 00 00 00 03 00 00 00 08 00 00 00 0A 00 00 00 48 07 00 00 85 20 01 00 01 00 00 00 ]

Been following your changes for a while now. I don't know how "known" this is but both mangos (i only verified for realmd on win) and TC suffer from fd/handler limit issues. Once the fd limit is reached the servers become unconnectable and this condition persists even if the number of connections being open drops below the fd limit. On Unix (where most likely ACE_Dev_Poll_Reactor is in use) ACE triggered epoll code goes into endless loop and never recovers unless the app is killed. Derex wrote a patch overloading the error handling and suspending the reactor to prevent this loop (https://github.com/derex/TrinityCore/commit/5f50d8c20f47bcf73ce6fce09e2e98bc8fe1ccbe). On Win no solution has been found so far as the ACE_TP_Reactor which is used there doesn't really trigger error handling as Unix/ACE_Dev_Poll_Reactor does. Long story short, you might want to verify if your proactor implementation suffers from the same problem. Shooting something like this at the servers might reveal that: #!/usr/bin/perl use IO::Socket; my @sockarr; for(my $i = 0; $i <= 5000; $i++) { if ($sockarr[$i] = IO::Socket::INET->new(Proto=>"tcp",PeerAddr=>"127.0.0.1",PeerPort=>"3724")) { print "connection: ${i} successful\\n"; } else { print "connection: ${i} failed\\n"; } } print "end"; sleep 10000; On Win mangos is using FD_SETSIZE 4096 from what i've seen, so this script might need to be started multiple times as Perl has a handler limit below 4096.

Chart produced by?

Thanks for your summary. I'd be interesting to hear more about why you turned SMF down. The db conversion is a one time process, so shouldn't matter that much i guess.

Mind sharing your thoughts about which open source BB to pick? For all i know PunBB is a pile of crap and well FluxBB forked from that. I mean there are tons of other options, so i'm kinda curious..

I beg to differ, at least with vmaps that is. http://paste2.org/p/620332

Still broken in http://github.com/mangos/mangos/commit/d17c1ab25f4906411cecf16ea0ff1e6338e0e1ae

http://lmgtfy.com/?q=deadlock

Still broken in 29e14e8c32be272ac4fb85cad286087abeeaec58.

mangos 0.12 doesn't, had to revert the mentioned commit to get it working again.

and *bump*..

After the recent change to threatlists i'm encountering alot of crashes related to those. Since i'm running an mtmaps patch i believe it is again an issue with threat-safety just like with bg queues before. So my question is: Is someone able to make those threatlist thread-safe? Any help is appreciated. p.s. Yes, mtmaps not supported bla bla, yet half the mangos folks are using them, but then again this is no official bug report in the bug report section...

Revision: mangos-0.12 e312f67f66f048a4dbeae7df230f714e27eea0cd Patches: none Description of bug: Mage talent Improved Scorch stops proccing from Scorch after c1b2ec is applied

Is this a memory, like mine from early days, or an observation from current retail activities?

I consider myself perfectly capable, thanks for asking. Sadly no helpful video footage found so far.

Since your sentences make absolutly no sense to me i pass on the discussion. Maybe someone else has more input..

"Terrain (that is, dirt and trees) only block Line of Sight indoors. All dirt and most trees do NOT block spells or abilities when fighting outdoors." Last time i checked the warsong graveyard is outdoors. Yet some confirmation from retail would be nice, my knowledge is from pre TBC on that topic.

Maybe i'm not fully up to speed, but since when does terrain count as LoS? http://www.wowwiki.com/Line_of_sight

Updated the patch again. It should also cover that other exploit method. Note: This patch is just a workaround for now since it is not yet proven to be the way to go. Ah yea, before i forget: If someone has a retail account, you could confirm some behavior here and help to create a proper patch for these issues: Put a box that contains other items like http://www.wowhead.com/?item=35232 in one of your inventory bags. Open that box, so you get the loot window. Now try to move that inventory bag which contains the box either - into an empty bank slot - or into an empty inventory bag slot - or switch it with another empty inventory bag And report results - Error msgs - What happens to the loot window - What happens to the box the loot window comes from

Mangos Version: : 0.12 rev 8569 805e4f6 Custom Patches: mtmaps, anticheat SD2 Version: 1498 Database Name and Version: TBCDB 0.0.2.2 http://paste2.org/p/537190 Server died during Player::SaveToDB but something with the transaction went wrong which resulted in the characters row in the characters.characters table got deleted. No, mysql is running fine and didn't crash. Yes the character existed before and wasn't saved for the first time. There are remains with his guid in other tables like character_spell Isn't the transaction supposed to be rolled back once the core crashes, loses the mysql connection and leaves an unfinished transaction behind? And of what is the crash about in the first place? (I can post the full dump if that is of any use)

Modified my patch after checking in with balrok. I think EQUIP_ERR_CANT_DO_RIGHT_NOW might be a more suitable error msg, since EQUIP_ERR_ITEM_LOCKED usually refers to locked chests, etc. and also it is used in Player::SwapItem() on a similar case. The second change prevents loot windows staying open if bags are being moved were the loot window is coming from. This might be not 100% retailish, but currently opened boxes are getting unlocked (ungreyed) on client side once you swap the bags they are located in. This behavior opens possibilites for further loot hacks.

What bug does the patch fix? What features does the patch add? Prevents duping items similar to 7470 For which repository revision was the patch created? 0.12 branch, presumably for master too Is there a thread in the bug report section or at lighthouse? If yes, please add a link to the thread. No. Who has been writing this patch? Please include either forum user names or email addresses. me From 0ff8ef674b1195eec6dbd853ad779848a979c34f Mon Sep 17 00:00:00 2001 From: leak <[email protected]> Date: Wed, 2 Dec 2009 01:54:32 +0100 Subject: [PATCH] release loot in case of bags being moved --- src/game/Player.cpp | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/src/game/Player.cpp b/src/game/Player.cpp index 3d041cb..e289cfc 100644 --- a/src/game/Player.cpp +++ b/src/game/Player.cpp @@ -9267,7 +9267,7 @@ uint8 Player::CanBankItem( uint8 bag, uint8 slot, ItemPosCountVec &dest, Item *p return swap ? EQUIP_ERR_ITEMS_CANT_BE_SWAPPED : EQUIP_ERR_ITEM_NOT_FOUND; if (pItem->m_lootGenerated) - return EQUIP_ERR_ITEM_LOCKED; + return EQUIP_ERR_CANT_DO_RIGHT_NOW; uint32 count = pItem->GetCount(); @@ -10437,6 +10437,10 @@ void Player::SwapItem( uint16 src, uint16 dst ) return; } + // release loot in case a bag is getting moved, prevents exploiting attempts + if(pSrcItem->IsBag() && IsBagPos (dst)) + GetSession()->DoLootRelease(GetLootGUID()); + // check unequip potability for equipped items and bank bags if(IsEquipmentPos ( src ) || IsBagPos ( src )) { -- 1.6.5.1.1367.gcd48 Comment: This whole field might need more research. I'm pretty sure there are other methods to exploit this issue. I can provide a full exploit guide for this specific issue if any dev is interested. For obvious reason i won't post it in public.

No you got me wrong. I was asking to provide the relevant mangos.conf values (like Infinity did) together with your mysql config. Stuff like vmaps and visibility range has a major impact on performance.