Xenithar

I will check on this tonight. I seem to recall this thread from ages ago, but have not checked lately. If it still exists I can work on it. The thing is, I would have to work on it one mob at a time, by using "modify scale x.y" until I find the right scale. Is there a way to extract the original, Blizzard scales from the client files? If not I can handle this, but it will come in increments and may take a while, unless everything needs to be scaled by some exact amount.

Alright, a quick fix has been been PR'd. It is located [url=https://github.com/mangoszero/server/pull/63]here[/url]. I am working on a better fix now.

Nice work! I'll mark this as solved.

This is a bug with either the vmaps creation or the server. I am experiencing this all over the place. Other symptoms will include mobs which aggro, then lose aggro, then repeat constantly, probably due to not being able to path to your player, despite being right next to you. Tanaris is a great place to see this issue in action. Get a hunter or warlock and TRY to keep the pet with you. They cannot even path over small dunes. So yes, either vmaps are broken during creation or the server-side code for handling mobs/pets is broken.

I am not familiar with the vmap/movement code personally, but if this remains open when I finish my next set of fixes and PR it, I will look into it. Hopefully somebody more familiar with the movement code can sort it before then.

Yeah, I did not understand what it fixed, but left it alone. I thought about doing a PR for >0, but wanted somebody familiar with why these lines were even in there to comment first. They appear to do nothing.

I disabled all the safe update features on the server and was able to execute the two lines of code and the other remaining 126 lines. All is good now, but there has to be a WHERE clause in these updates. I turned my safe updates settings back on after updating to 21_2_1. I am good and can continue work on the server, but something should be done about this. I will leave this open since the issue has not been fixed.

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]

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.

Alright, I believe I just figured it out! If I start my server and play, all is good. However, if I start it and let the connections time-out, then login and play, I get loads of SQL connection errors, players are NOT saved, and nothing appears to work correctly. I then tried restarting the server. Everything works until the connection times out. This leads me to two conclusions.

First, we are not closing idle connections. This is a no-no.
Second, after the connection is closed by the DB engine, MaNGOS does not realize it so it is sending queries to the now closed connections. This is why it instantly fails when a player logs in or out.

So, how do we fix this? It is going to take some collaboration to correct this issue. We have to fix BOTH of the issues above.

First, we need to agree on a way to handle idle connections. It is a best practice to close them using "mysql_close". Our time-out should be less than the MySQL default of 600 seconds (ten minutes) or the DB engine will close them forcefully. My thinking is that on a populated server (one to a million players) the connections will be used frequently enough that we never hit our time-out and all will be good. If nobody is on, then it doesn't matter if they close.

Second, the simple fix for the DB engine closing the connection would be to check it before any query is run. I do not remember the code off the top of my head, but the last time I did a C++, Windows app that used MySQL, I used some object method which checked to see if the connection was good before I ran my query. If not, I simply recreated it and updated the handle to the connection. We should be able to do this here. This solution is a band-aid. We should NOT be keeping six or eight idle connections open when nobody is on.

One thing that bothers me however, is that once all of the connections timed out, I had my fiancée login. Several connections WERE created again, including four to the realm database and one to the characters database. However, despite there being a connection to the character DB, I got SQL errors. This could mean that despite the connection being there, some of the server code is not being updated to the new connection handle, preventing it from using the connected, valid connection. I have no idea how to easily troubleshoot that.