Xenithar

I can reproduce this in the current R20 build. Changing status to confirmed. Happens in 32bit and 64bit builds. Internal ACE will not build mmaps generator. External ACE is fine.

I had no trouble with this on Debian a week or two ago. I will try this right now and get back to this ticket ASAP. *UPDATE* I starting the build process using this configuration. [code] cmake .. -DDEBUG=1 -DUSE_STD_MALLOC=1 -DACE_USE_EXTERNAL=0 -DBUILD_TOOLS=1 -DSCRIPT_LIB_SD2=1 -DSCRIPT_LIB_ELUNA=1 -DCMAKE_INSTALL_PREFIX=/home/---/zero [/code] I will respond when finished. This is Debian Wheezy (7.7).

So AHBot will be a submodule now, like Eluna and SD2?

Seems like the opposite of the current bug in Zero. In Zero, it buys your stuff, but doesn't sell anything. Also, this should be a bug report, not a feature request.

Alright, I have a ticket open about the broken pipe, so we can worry with it there. I will be testing server shutdowns shortly.

This hasn't worked for me for months. I assume it is due to the major overhaul R20 is getting, but it does not work here either. Horde in Horde cities nor Alliance in Alliance cities. I just rebuilt last weekend. I can build again if needed, otherwise I will build again this weekend as scheduled.

I will try this evening. I can tell you that the timed shutdown command causes a broken pipe EVERY TIME for the last two weeks. I will test all shutdown commands tonight on Linux.

I clean the WDB cache weekly when I rebuild Zero. I have an AD script I execute that cleans it out on all of my domain gaming rigs. Failure to do that can result in bad data in-game.

Note that those may not be correct for Zero. Why? We didn't have paladins in Zero on The Horde, for one. Those toons also appear different in your screenshots than they do in-game in Zero. I'm not trying to rain on your parade, just trying to be as accurate as possible. You've done a ton of awesome work recently.

Happened again tonight, once. Did not happen after. [code] creature 1 stopped attacking creature 10 creature 11 stopped attacking creature 10 player 16 stopped attacking creature 10 SET JUST_DIED Aura 3 now is remove mode 4 Aura 3 now is remove mode 4 Aura 79 now is remove mode 5 Aura 142 now is remove mode 5 Aura 133 now is remove mode 5 Aura 79 now is remove mode 5 Aura 101 now is remove mode 5 Aura 133 now is remove mode 5 Aura 31 now is remove mode 5 Aura 110 now is remove mode 5 Aura 52 now is remove mode 5 Aura 57 now is remove mode 5 Aura 157 now is remove mode 5 Aura 42 now is remove mode 5 DealDamageEnd returned 14 damage Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb20f1b70 (LWP 3105)] 0x00000007 in ?? () (gdb) backtrace #0 0x00000007 in ?? () #1 0x0882e142 in Aura::UpdateAura (this=0xb77c43f0, diff=101) at /home/---/zero/src/server/src/game/WorldHandlers/SpellAuras.h:455 #2 0x0882d4d4 in SpellAuraHolder::Update (this=0xc2d0030, diff=101) at /home/---/zero/src/server/src/game/WorldHandlers/SpellAuras.cpp:5445 #3 0x086a05a5 in SpellAuraHolder::UpdateHolder (this=0xc2d0030, diff=101) at /home/---/zero/src/server/src/game/WorldHandlers/SpellAuras.h:154 #4 0x0868b059 in Unit::_UpdateSpells (this=0xef040d8, time=101) at /home/---/zero/src/server/src/game/Object/Unit.cpp:2979 #5 0x08681f0a in Unit::Update (this=0xef040d8, update_diff=101, p_time=101) at /home/---/zero/src/server/src/game/Object/Unit.cpp:329 #6 0x0871b0a6 in Creature::Update (this=0xef040d8, update_diff=101, diff=101) at /home/---/zero/src/server/src/game/Object/Creature.cpp:582 #7 0x086b641e in Pet::Update (this=0xef040d8, update_diff=101, diff=101) at /home/---/zero/src/server/src/game/Object/Pet.cpp:600 #8 0x087da370 in WorldObject::UpdateHelper::Update (this=0xb20effa4, time_diff=101) at /home/---/zero/src/server/src/game/Object/Object.h:473 #9 0x087daada in MaNGOS::ObjectUpdater::Visit (this=0xb20f1180, m=...) at /home/---/zero/src/server/src/game/WorldHandlers/GridNotifiersImpl.h:54 #10 0x087e7b78 in VisitorHelper (v=..., c=...) at /home/---/zero/src/server/src/framework/GameSystem/TypeContainerVisitor.h:72 #11 0x087e77f0 in VisitorHelper > > (v=..., c=...) at /home/---/zero/src/server/src/framework/GameSystem/TypeContainerVisitor.h:85 #12 0x087e71ae in VisitorHelper > > > (v=..., c=...) at /home/---/zero/src/server/src/framework/GameSystem/TypeContainerVisitor.h:86 #13 0x087e645f in VisitorHelper > > > > (v=..., c=...) at /home/---/zero/src/server/src/framework/GameSystem/TypeContainerVisitor.h:98 #14 0x087e5232 in TypeContainerVisitor > > > > >::Visit (this=0xb20f1178, c=...) at /home/---/zero/src/server/src/framework/GameSystem/TypeContainerVisitor.h:127 #15 0x087e3499 in Grid > > >, TypeList > > > >::Visit (this=0xe1577ac, visitor=...) at /home/---/zero/src/server/src/framework/GameSystem/Grid.h:111 #16 0x087e0ca4 in NGrid > > >, TypeList > > > >::Visit > > > > (this=0xe149b00, x=@0xb20f00bc: 15, y=@0xb20f00b8: 12, visitor=...) at /home/---/zero/src/server/src/framework/GameSystem/NGrid.h:360 #17 0x087dcc30 in Map::Visit > > > > > (this=0xec26088, cell=..., visitor=...) at /home/---/zero/src/server/src/game/WorldHandlers/Map.h:446 #18 0x087d3ef0 in Map::Update (this=0xec26088, t_diff=@0xb20f123c: 101) at /home/---/zero/src/server/src/game/WorldHandlers/Map.cpp:521 #19 0x087d7cbc in DungeonMap::Update (this=0xec26088, t_diff=@0xb20f123c: 101) at /home/---/zero/src/server/src/game/WorldHandlers/Map.cpp:1384 #20 0x088e2c0a in MapManager::Update (this=0xb3d88c0, diff=48) at /home/---/zero/src/server/src/game/WorldHandlers/MapManager.cpp:184 #21 0x087f0b7b in World::Update (this=0x8e50290, diff=48) at /home/---/zero/src/server/src/game/WorldHandlers/World.cpp:1498 #22 0x085b75df in WorldRunnable::run (this=0xbb65148) at /home/---/zero/src/server/src/mangosd/WorldRunnable.cpp:66 #23 0x0898c979 in ACE_Based::Thread::ThreadTask (param=0xbb65148) at /home/---/zero/src/server/src/shared/Threading.cpp:197 #24 0xb7f43171 in ACE_OS_Thread_Adapter::invoke() () from /usr/lib/libACE-6.0.3.so #25 0xb7f051cf in ace_thread_adapter () from /usr/lib/libACE-6.0.3.so #26 0xb77ccc39 in start_thread () from /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 #27 0xb77399fe in clone () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 [/code] Happened once when we started RFK. We came back and finished, no more crashes. This is very random.

I just rebuilt a few hours ago and I know Lord Kazzak has something like 2665HP, which is incorrect. It appears as though it needs some more work.

In the alpha and first part of the beta there was a huge quest-chain planned for the air totem. it was buggy and got dumped. They promised to do it right, but I do not remember it happening, and when they went all "We're World of Daycare!" on us and simplified it for the kiddies, we lost all of our hard-earned totems. That made me sad. Oh, we were also promised, since the beta, a sham UI to control totems and such. They gave us a piece of crap in either TBC or WoTLK, I forget which. Many things were never completed though. I can show you loads of areas from the alpha and beta which still existed in Vanilla, but were difficult to reach. The most well-known areas were probably the airport by IF and the village below it.

I have never seen the UDB message you just mentioned. What would cause it to show up?

You forgot one. Baron Revilgaz, entry 2496. He is in Booty bay.

How about "Ah! I've been expecting you!". That wouldn't be played out. In all seriousness though, if you look at 1531 Prate says the following. [quote] For the time being. I shall give you what you need to focus your spells and to call upon the spirits of air. Take this totem, and when you are ready, train with me some more. [/quote] If you change the 1531 in that link to 1532, there is no text. Perhaps this is an actual Blizzard bug that was never fixed in Vanilla. Perhaps we should use the same text on both?

Wow, nicely done! Once your PR is merged I'll clone the latest DB and apply the fixes.

Alright, calling it quits for the night. I have my day job tomorrow and I must get up at 0630hrs, so I need to sleep. I have tried the following so far, none of which worked. [list] [*]Rebuilding the realm and world servers [*]Running the realm server as a daemon outside GDB [*]Running the realm server normally outside of GDB [*]Running the realm server as a daemon in GDB [*]Running the realm server normally inside GDB [*]Dropping and recreating the realmlist database [*]Doing my configuration files from scratch [/list] I will sleep on it and try again tomorrow. Oh, and I checked my internal DNS server, my router, and everything else. The issue is in the realm server. I may start editing code on my end for testing purposes to find out what thread is starting and dying quickly. I also need to figure out why so many things are not being logged despite being coded to do so.

Sorry, I replied in our thread. I will post it here with my server name and address hidden for my own security reasons. [code] '1', 'HiddenName', 'my.hostname.com', '8085', '1', '64', '2', '0', '0.0625', '5875 6005 6141 ' [/code] Also, note that when starting the realm server in debug, a thread starts and exits instantly. Seems odd and may be the issue. I will debug this for a while tonight because it is a real show-stopper. If I figure it out I will report back. [code] Reading symbols from /home/---/zero/bin/realmd...done. (gdb) run Starting program: /home/---/zero/bin/realmd [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1". [New Thread 0xb765eb70 (LWP 3076)] [Thread 0xb765eb70 (LWP 3076) exited] 20003 [realm-daemon] to stop. Using configuration file ../etc/realmd.conf. Login Database total connections: 2 MySQL client library: 5.5.38 MySQL server ver: 5.5.38-0+wheezy1 MySQL client library: 5.5.38 MySQL server ver: 5.5.38-0+wheezy1 [New Thread 0xb765eb70 (LWP 3078)] Added realm id 1, name 'HiddenName' [/code] *UPDATE* I am seeing code in the main source file that is not being logged in my log-file. [code] DETAIL_LOG("%s (Library: %s)", OPENSSL_VERSION_TEXT, SSLeay_version(SSLEAY_VERSION)); if (SSLeay() { DETAIL_LOG("WARNING: Outdated version of OpenSSL lib. Logins to server may not work!"); DETAIL_LOG("WARNING: Minimal required version [OpenSSL 0.9.8k]"); } DETAIL_LOG("Using ACE: %s", ACE_VERSION); [/code] The log lines detailing my SSL and ACE libraries are not appearing in my log. This is under both 32bit and 64bit Debian.

Oh that makes sense. It is strange though, the one time I did this in Linux I do not remember it taking a long time. I will try this in Linux again and see what happens. I am only curious here. I agree that a warning should be issued when using a debug build since it takes so very long.

Can Visual Studio not set the CMake parameters? I choose what I want to build in debug and release modes. Code::Blocks allows me to set my CMake parameters and I would think that Visual Studio could also. However, I do not know how it would be done.

I PM'd you on this matter. I was simply trying to state above that if we do something that is core functionality in either of the two modules, we need to do it in both since users can choose one or the other. I did not mean to come across as hostile.

Antz, this issue exists in my copy of R20 under Debian. I did a fresh clone about four days ago. The problem still appears to exist however. I will double-check to be sure in a few hours when I can.

I was going to dig into the gossip table but did not. I have been going all day. Good job, quick fix!