Xenithar

I found the issues. You can't do safe updates without specifying an index. I removed all commenting, coding, everything except SQL from the update and ran it. It ran until it hit the following lines. [code] update dbdocsfields SET FieldComment = replace(FieldComment, 'table', 'table'); update dbdocsfields SET fieldNotes = replace(fieldNotes, 'table', 'table'); [/code] There is no index given so it was failing due to not being a safe operation. This was not being shown in the errors log, but it was causing the rollback flag to trip. All updates MUST specify an index! I now have to delete everything up to this line and figure out how to correct it so I can complete the update.

I have uploaded a screenshot of the issue. I modified the results to show the structure and content variables also. The issue is that "bRollback" is TRUE and it always rolls back, but no errors are logged. Is something missing which sets bRollback to FALSE? Again, the other updates worked, although 24 and 25 both have a space or some other character as the first character in the file. I have to delete this invisible character or the update will not run at all. I am guessing these were written in something in Windows which is not unicode aware?

Done! The MinLevel is now 26 as found [url=http://www.wowhead.com/quest=1106/martek-the-exiled]here[/url] and is now a part of my [url=https://github.com/mangoszero/database/pull/30]current pull request[/url].

This is an issue, but the information I am finding says it can be started at 26, not 31. It should be 26 and 35. I am creating a fix now.

I have made a [url=https://github.com/mangoszero/database/pull/30]pull request[/url] which fixes the initial issue. The files 22-25 do not appear to have the spaces when edited in nano. I will look into them more and do a PR if the issue is the file being edited in Windows or something. I still have not figured out why 25 will not work.

I can confirm that this is indeed a bug. I have already made a [url=https://github.com/mangoszero/database/pull/30]pull request[/url] which addresses this issue and corrects it. *EDIT* I forgot to link to the information which backs up the initial complaint. It is now linked! [url=http://www.wowhead.com/quest=3022/handle-with-care]Quest 3022 Information[/url]

I am a fairly dedicated Linux user and do all of my work on MaNGOS and databases in Linux. I currently use Gentoo GNU/Linux 64bit, but the content here should apply to many other distros as well. You see, I just figured out that if you're running KDE (not Gnome, XFCE, LXDE, or others) and using the Dolphin file browser, you can REALLY make using GIT simple! All you need to do is install the Dolphin plugins package for your distro. On Gentoo I had to emerge "dolphin-plugins". Your method may vary. Once the plugins are installed, open Dolphin and go to "Settings->Configure Dolphin" or "Control->Configure Dolphin". Enable the GIT support by checking the box next to "git". Press OK, close Dolphin, and then re-open it. Navigate to a folder containing a local GIT repo and right-click somehwere inside. YOu can now switch branches, create branches, push, pull, commit, and more with a GUI interface! I wish I had known this a year or so back when I was struggling to learn GIT. Oh well, I hope it helps another person!

OK, I am an idiot. I just looked at your code and I see ">0". I was exhausted the last time I viewed this and thought that you had specified an entry number. My bad. I'll PR this fix today. *UPDATE* 21_1_22 is also broken. There are two spaces in front of the first line. I will fix this also. *UPDATE* 21_1_23 also has a space in front of line 1... *UPDATE* As do 24 and 25. Also, 25 always fails without a reason. I will try to figure out why.

As it is currently written, it can affect multiple records which match the criteria. If we put in an entry clause, it can only affect one entry. What I am asking, and will find out shortly, is how many entries match that criteria. I'll just do a SELECT statement with the search criteria to see how many results we get.

I will PR that if that is the ONLY entry being updated. Is that confirmed?

This is still happening. It did not happen last week and I did not update (lack of time, but I am about to have three paid weeks off) and it happened today. I am doing a fresh clone and build, and we will see if it starts. Currently I cannot start the server at all, so after this build finishes, if the bug is fixed, I SHOULD be able to start it up. Below is a dump from this morning. [code] WORLD: Sent SMSG_QUESTGIVER_STATUS for Creature (Entry: 6929 Guid: 4661) WORLD: Received opcode CMSG_QUESTGIVER_STATUS_QUERY - for Player Tyree (Guid: 7) to Creature (Entry: 5611 Guid: 706) WORLD: Sent SMSG_QUESTGIVER_STATUS for Creature (Entry: 5611 Guid: 706) WORLD: Received opcode CMSG_QUESTGIVER_STATUS_QUERY - for Player Tyree (Guid: 7) to Creature (Entry: 13418 Guid: 53618) WORLD: Sent SMSG_QUESTGIVER_STATUS for Creature (Entry: 13418 Guid: 53618) WORLD: Received opcode CMSG_QUESTGIVER_STATUS_QUERY - for Player Tyree (Guid: 7) to Creature (Entry: 9550 Guid: 46973) WORLD: Sent SMSG_QUESTGIVER_STATUS for Creature (Entry: 9550 Guid: 46973) WORLD: Received opcode CMSG_QUESTGIVER_STATUS_QUERY - for Player Tyree (Guid: 7) to Creature (Entry: 15188 Guid: 6504) WORLD: Sent SMSG_QUESTGIVER_STATUS for Creature (Entry: 15188 Guid: 6504) Got packet, opcode 02, size 24 STORAGE_SIZE: 24 02 11 00 F3 ED A1 1C 01 | 53 83 5E 03 E9 E9 00 74 25 E9 E9 E9 E9 E9 E9 E9 Handle data CHECKSUM IS VALID ServerTicks 116404702, RequestTicks 116367402, CLientTicks 56525651 Waittime 37300 RESULT MODULE_CHECK passed CheckId 769 account Id 4 RESULT MODULE_CHECK passed CheckId 768 account Id 4 RESULT MEM_CHECK passed CheckId 638 account Id 4 RESULT PAGE_CHECK passed CheckId 669 account Id 4 RESULT PAGE_CHECK passed CheckId 668 account Id 4 RESULT PAGE_CHECK passed CheckId 667 account Id 4 RESULT PAGE_CHECK passed CheckId 666 account Id 4 RESULT PAGE_CHECK passed CheckId 665 account Id 4 RESULT PAGE_CHECK passed CheckId 664 account Id 4 RESULT PAGE_CHECK passed CheckId 663 account Id 4 WORLD: Received opcode CMSG_GOSSIP_HELLO WORLD: Sent SMSG_GOSSIP_MESSAGE from Creature (Entry: 13420 Guid: 53620) WORLD: CMSG_GOSSIP_SELECT_OPTION [SD3]: Gossip selection, sender: 0, action: 3 WORLD: Sent SMSG_LIST_INVENTORY [ ] 0% [ ] 0% SQL ERROR: wrong amount of parameters (2 instead of 0) SQL ERROR: statement: UPDATE characters SET stored_dishonorable_kills = stored_dishonorable_kills + %u WHERE guid = %u /usr/src/zero/server/src/shared/Database/SqlPreparedStatement.cpp:68: Error: Assertion in Execute failed: false Stack Trace: /home/ryana/zero/bin/mangosd(_ZN9ObjectMgr15FlushRankPointsEj+0x27d) [0xaa9a93] /home/ryana/zero/bin/mangosd(_ZN5World22ServerMaintenanceStartEv+0x68) [0xd638a2] /home/ryana/zero/bin/mangosd(_ZN5World6UpdateEj+0x378) [0xd622d6] /home/ryana/zero/bin/mangosd(_ZN13WorldRunnable3runEv+0x64) [0xa395a4] /home/ryana/zero/bin/mangosd(_ZN9ACE_Based6Thread10ThreadTaskEPv+0x37) [0xeb4e51] /usr/lib/libACE-6.0.3.so(_ZN21ACE_OS_Thread_Adapter6invokeEv+0xa6) [0x7ffff7745636] /lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50) [0x7ffff5edab50] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7ffff5c2495d] mangosd: /usr/src/zero/server/src/shared/Database/SqlPreparedStatement.cpp:68: bool SqlStatement::Execute(): Assertion `"false" && 0' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 0x7fffefa75700 (LWP 25120)] 0x00007ffff5b7b165 in raise () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) backtrace #0 0x00007ffff5b7b165 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff5b7e3e0 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007ffff5b74311 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x0000000000e99ce4 in SqlStatement::Execute (this=0x7fffefa74d20) at /usr/src/zero/server/src/shared/Database/SqlPreparedStatement.cpp:68#4 0x0000000000acb254 in SqlStatement::PExecute ( this=0x7fffefa74d20, param1=1, param2=3) at /usr/src/zero/server/src/shared/Database/SqlPreparedStatement.h:512 #5 0x0000000000aa9a93 in ObjectMgr::FlushRankPoints (this=0x162e4f0, dateTop=42350) at /usr/src/zero/server/src/game/Object/ObjectMgr.cpp:2760 #6 0x0000000000d638a2 in World::ServerMaintenanceStart (this=0x162d8c0) at /usr/src/zero/server/src/game/WorldHandlers/World.cpp:1965 #7 0x0000000000d622d6 in World::Update (this=0x162d8c0, diff=50) at /usr/src/zero/server/src/game/WorldHandlers/World.cpp:1554 #8 0x0000000000a395a4 in WorldRunnable::run (this=0x69e44e0) at /usr/src/zero/server/src/mangosd/WorldRunnable.cpp:70 #9 0x0000000000eb4e51 in ACE_Based::Thread::ThreadTask (param=0x69e44e0) at /usr/src/zero/server/src/shared/Threading/Threading.cpp:197 #10 0x00007ffff7745636 in ACE_OS_Thread_Adapter::invoke() () from /usr/lib/libACE-6.0.3.so #11 0x00007ffff5edab50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #12 0x00007ffff5c2495d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #13 0x0000000000000000 in ?? () (gdb) next Single stepping until exit from function raise, which has no line number information. [Thread 0x7fffee272700 (LWP 25123) exited] [Thread 0x7fffeea73700 (LWP 25122) exited] [Thread 0x7fffefa75700 (LWP 25120) exited] [Thread 0x7ffff0276700 (LWP 25119) exited] [Thread 0x7ffff209f700 (LWP 25118) exited] [Thread 0x7ffff493a700 (LWP 25117) exited] [Thread 0x7ffff513b700 (LWP 25116) exited] [Thread 0x7ffff5b48700 (LWP 25115) exited] [Thread 0x7ffff7fed720 (LWP 25111) exited] Program terminated with signal SIGABRT, Aborted. The program no longer exists. (gdb) [/code] Any attempt to start the server results in the same crash. Again, I will see if rebuilding fixes this.

I will look into this when I get home if nobody else beats me to it.

I am closing this. I did a PR which was already merged on this issue.

That fixed it. I reset the MySQL configuration to a ten-minute time-out and set MaxPingTime to 5, and it has been running for 36hrs without a hitch. I will do a PR to fix the configuration file this evening. Credit goes to H0zen for mentioning the setting. I do now see how it affects the connection manager in the code, but this is good. I still believe that we need a way to detect broken connections however, to avoid a player losing an hour of play in the event something else causes a connection to break, but this is not high priority by any means.

Graveyard and Library, the two without doors in front. Both refused entry to my 29 rogue and 33 hunter.

I have not seen MaxPingTime referenced in the SQL classes I saw, but I admit I have not been over every line. I do see it in the config file. I will set it to five minutes (half the default time-out now) and see how things run. Thank you for pointing this out. If it works, I will simply do a PR with an updated MaxPingTime default.

Ah OK, I misunderstood you. My reason for dropping by is that the SQL issue caused a server to go completely down. I am already working on a fix, but this server is bone-stock. I have a test server I do my own modifications on. [code] Map::GetHitPosition vmaps corrects gained with static objects! new dest coords are X:-10585.773438 Y:-1194.180786 Z:28.749500 [ ] 0% SQL ERROR: wrong amount of parameters (2 instead of 0) SQL ERROR: statement: UPDATE characters SET stored_honorable_kills = stored_honorable_kills + %u WHERE guid = %u /usr/src/zero/server/src/shared/Database/SqlPreparedStatement.cpp:68: Error: Assertion in Execute failed: false Stack Trace: /home//zero/bin/mangosd(_ZN9ObjectMgr15FlushRankPointsEj+0x23a) [0xaaa654] /home//zero/bin/mangosd(_ZN5World22ServerMaintenanceStartEv+0x68) [0xd644aa] /home//zero/bin/mangosd(_ZN5World6UpdateEj+0x378) [0xd62ede] /home//zero/bin/mangosd(_ZN13WorldRunnable3runEv+0x64) [0xa3a254] /home//zero/bin/mangosd(_ZN9ACE_Based6Thread10ThreadTaskEPv+0x37) [0xeb5a59] /usr/lib/libACE-6.0.3.so(_ZN21ACE_OS_Thread_Adapter6invokeEv+0xa6) [0x7ffff7745636] /lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50) [0x7ffff5edab50] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7ffff5c2495d] mangosd: /usr/src/zero/server/src/shared/Database/SqlPreparedStatement.cpp:68: bool SqlStatement::Execute(): Assertion `"false" && 0' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 0x7fffefa75700 (LWP 10736)] 0x00007ffff5b7b165 in raise () from /lib/x86_64-linux-gnu/libc.so.6 [/code] No issues prior to that. I did hide my username in the dump above, but I changed nothing else. This may be a different issue though. I had killed some Alliance NPCs earlier and managed to nail two dishonorable kills in the process. Perhaps when it was trying to update my honor this bug reared its head.

Actually the correct fix would be to determine the connection timeout when connected to the DB server and set all connections to maybe half of that. If a query is sent before the local timeout expires, reset the timer. If not, it does a graceful close via mysql_close. What I am proposing is not a hack, but something fairly standard in business apps. Just check the connection prior to sending a query. I am still going over the MySQL code in MaNGOS, but my assumption is that this will only need to be applied in one location. That is to say, in one class. I am currently still figuring out program-flow through the classes, but hope to have it figured out by Friday and begin working on a fix shortly thereafter.

I got off work early today so I came home and did some testing. If I start the server and join within fifteen minutes the server is fine for as long as you play. Once the last player quits, you have roughly fifteen minutes until the DB server breaks connections. After that, you can no longer save your character or update server info such as population. Here are my test cases. Started server, joined, played for an hour Quit, joined five minutes later, played for thirty minutes Quit, waited EXACTLY sixteen minutes (one minute beyond timeout), joined, had SQL errors Started the server, waited sixteen minutes, joined, had SQL errors Started the server, waited fourteen minutes, joined, played for thirty minutes Quit, waited fourteen minutes, joined, played fifteen minutes Quit, waited sixteen minutes, joined, had SQL errors What I am getting at, is that this is reproducible. Once your SQL timeout is reached and the connection is broken, we are hosed. However, if you have upgraded MySQL over the years your default will be 28,800 seconds, or eight hours as it was when you first installed it. This means that if you run a server all the time, such as Covenant, as long as a single player logs into the server prior to the timeout, the timeout is reset and the server chugs along. However, with a new install on a new system with a recent MariaDB or MySQL, this problem rears its ugly nose. I am currently digging into the MySQL client code in MaNGOS, but it is slow-going. Not my coding style and I need to understand the program-flow before I make changes, but my plan is to simply detect a closed connection and, if it is closed, reopen it prior to doing the query.