jackpoz

https://medium.com/swlh/code-reviews-can-make-or-break-your-team-a3cfdcc15de1 Code Reviews Can Make or Break Your Team

After contacting OpenHub support, asking to remove the nonexistent 4.3.4 branch from https://www.openhub.net/p/TrinityCore/enlistments and waiting a week, OpenHub finally crawled TC github repos (all this without even having Manager permissions on OpenHub) .

​it's rare to see someone spell Lua correctly instead of the more common LUA/lua

Broken once again according to https://www.openhub.net/p/TrinityCore/enlistments

http://www.codeproject.com/Articles/783574/Five-Phases-of-Developer-Maturity "Five Phases of Developer Maturity"

https://github.com/TrinityCore/TrinityCore/commit/f07fe63e50062941dd99ce719f27f6d09ecfbd7d

Just tested sending CMSG_BATTLEFIELD_MGR_ENTRY_INVITE_RESPONSE with botfarm with 4 bots at Dalaran, Honor Hold, Darnassus and Elwynn Forest with 3 Map Threads and helgrind running and all in the same raid with me too, I saw them leaving the party then worldserver stopped with "Killed" message in the console. We can mark this issue as "reproduced". This is the full race condition log, you can see 2 MapThreads both calling indeed the function you said The whole BattlefieldHandler.cpp looks unsafe, not sanitizing any input (all I had to do was send CMSG_BATTLEFIELD_MGR_ENTRY_INVITE_RESPONSE with Wintergrasp battlefield ID). For example WorldSession::HandleBfExitRequest() modifies Battlefield data even if the player is on another map. Battlefield-related packets that are supposed to be sent by the client only when already in the battle should check for mapid, the other ones should be set as PROCESS_THREADUNSAFE

​I tele'd to the area with 1 party member, joined the queue, .bf start 1, accepted: the other party members not in Wintergrasp didn't get any popup.

world thread is on hold when updating maps through map threads, you need to specify at least 2 to trigger helgrind reports (or have any real world issue for the matter)

was that with MapUpdate.Threads > 1 ?

He's not gonna get an useful crashlog with "Release" mode

Ah that's why I didn't get any report, I tested Random Battleground, not Wintergrasp. Wintergrasp is disabled by default and should be enabled only by developers who want to work on it, the config file describes it as "experimental" https://github.com/TrinityCore/TrinityCore/blob/3.3.5/src/server/worldserver/worldserver.conf.dist#L2268 . Your findings are most likely right and there might be many more issues related to Wintergrasp. I'll give it another try with Helgrind.

Helgrind didn't report anything joining a random bg while in group, tested with 3 players. After the bg I was still in the initial group too, is that expected ?

could you post some detailed how to reproduce steps to trigger the race condition ?

https://www.javacodegeeks.com/2015/07/a-few-valid-reasons-to-reject-a-bug-fix.html

there is https://github.com/TrinityCore/TrinityCore/pull/14104 for FreeBSD but the author of that PR disappeared. if you know C++ and are interested into maintaining FreeBSD support for TrinityCore, you could clean up that PR and resubmit it.

did you trigger the race under helgrind ?

https://www.livecoding.tv/

Try triggering that HandleBfEntryInviteResponse() with 2 players on 2 different maps with 2 MapThreads with worldserver running under helgrind, it should spot the race condition for you

http://henrikwarne.com/2015/04/16/lessons-learned-in-software-development/ "Lessons Learned in Software Development"

That's a known issue reported by travis too at https://travis-ci.org/TrinityCore/TrinityCore#L408 . You can check the build status on the https://github.com/TrinityCore/TrinityCore homepage, 6.x build status is "failing" at the moment; in these cases wait for someone to fix the build, hopefully this will save you all those steps next time.

You can filter out any issue labeled with 4.3.4 and 6.x to get the list of 3.3.5 issues : https://github.com/TrinityCore/TrinityCore/issues?q=is%3Aopen+is%3Aissue+-label%3ABranch-4.3.4+-label%3ABranch-6.x+ Just add a - sign before the filter so that it looks like -label:Branch-4.3.4

when we apply a label it means "this issue affects only this branch", so we can filter (or filter out) them

can you reproduce the memory leak ?

Still broken according to https://www.openhub.net/p/TrinityCore/enlistments Now it works, thx. May I suggest to add ALL TrinityCore repositories ? like WPP and others