MySQL Problem
by Dennis Trevillyan · in Torque 3D Professional · 09/05/2011 (1:36 pm) · 10 replies
I've been using MySQL for my project, based on this resource: www.garagegames.com/community/blogs/view/13528. Until today it has worked fine. I have a MySQL database located on a LAMP server that contains login information such as password and character information. The client connects to the database to get the password to authenticate login and then proceeds to download the player character information. This information is displayed in a dialog to allow the user to select the character to play with. There are six fields that are retrieved from the database: name, spawn_class, spawn_datablock, spawn_point,race, and gender. I've tried older versions from SVN and they work fine. But, if I recompile the older versions it doesn't work any longer. The first field is retrieved, the character name, and the engine crashes on the second one. I've compared the solution and project files, between the SVN version that works and the current version and there are no differences. I've compared the script and source files. Any changes that were there were reverted to the original but it still doesn't work.
I can only conclude that there is something new happening during the compile or link process. Has anyone else seen anything similar? I'm using VS Express 2008 SP1 with MySQL Connector C 6.0.2.
I can only conclude that there is something new happening during the compile or link process. Has anyone else seen anything similar? I'm using VS Express 2008 SP1 with MySQL Connector C 6.0.2.
About the author
#2
09/07/2011 (5:22 am)
Looks like he did - VS 2008 Express. Perhaps the Platform SDK has the additional source and libraries that don't come with Express - once upon a time that worked for me, but you have to download it separately from Microsoft.
#3
@Richard, I don't have the Platform SDK but I don't think you need it now do you? I will give it a shot though.
Here's what I've learned so far. As described in the original post the query should return four rows each with six cells. Using the mysql function %mysql.NumRows(); shows four rows and %mysql.NumFields(); shows six fields. The first field in each is fine, the sixth field will not crash the engine but results in an error that it is not available in the result returned by fetchRow. The second field will crash the engine. I haven't tried those in between. Unfortunately since all of this happens in libmysql.dll it isn't really clear what is going on. I've been trying to build a debug version of this dll but figuring out how has been slow.
I'll give the Platform SDK a shot. thanks for the suggestions.
09/07/2011 (3:37 pm)
@AF, yes I have used VS 2008 Express throughout. This resource has worked fine for me for about a year both using local and internet based servers. @Richard, I don't have the Platform SDK but I don't think you need it now do you? I will give it a shot though.
Here's what I've learned so far. As described in the original post the query should return four rows each with six cells. Using the mysql function %mysql.NumRows(); shows four rows and %mysql.NumFields(); shows six fields. The first field in each is fine, the sixth field will not crash the engine but results in an error that it is not available in the result returned by fetchRow. The second field will crash the engine. I haven't tried those in between. Unfortunately since all of this happens in libmysql.dll it isn't really clear what is going on. I've been trying to build a debug version of this dll but figuring out how has been slow.
I'll give the Platform SDK a shot. thanks for the suggestions.
#4
I don't know if the Platform SDK has anything to do with it, I just vaguely remember having an issue with missing lib files and that's how I solved it.
Any service packs or OS updates lately?
09/07/2011 (3:56 pm)
Do you have the source download for MySQL? If you compile a debug version of the dll you might have more luck stepping through it.I don't know if the Platform SDK has anything to do with it, I just vaguely remember having an issue with missing lib files and that's how I solved it.
Any service packs or OS updates lately?
#5
09/07/2011 (4:11 pm)
I downloaded the source code for the C connector last night but didn't have much luck figuring out how to generate the project files using cmake. to make things worse I found one set of instructions on the website and a second in the readme file included in the download. I'm going to start reading the cmake docs on their wiki to see if I can't figure it out. I agree that a debug version of the mysql dll would be a good way to understand what is going on.
#6
09/07/2011 (5:52 pm)
Well isn't this surprising. As I was working my way through the cmake files in an attempt to figure that out I found a visual studio solution file! Loaded it up in VS and it compiled first time. Attached it to the running client and it worked like a charm. Guess that's what I get for reading the instructions. You should never read those dang things!
#7
09/07/2011 (9:48 pm)
LOL - awesome! I'm with you, though - I want to know why it just stopped working in the first place. Kinda strange, but I guess up and running is better than sitting and scratching your head....
#8
It appears that the crash is actually happening in ntdll.dll in Windows. I wonder what Microsoft has been up to lately? I think I'll shift my focus in that direction for a bit. Certainly don't see anything wrong in the code at this point.
09/08/2011 (6:29 pm)
The debug version of libmysql.dll helped to understand how the this resource works but it hasn't answered the question of why it is crashing. The data gets loaded from the MySQL server using an imported function. So unfortunately I can't see anything more here than I could in the T3D code. It appears that the crash is actually happening in ntdll.dll in Windows. I wonder what Microsoft has been up to lately? I think I'll shift my focus in that direction for a bit. Certainly don't see anything wrong in the code at this point.
#9
In line 392 of mysql.cc
was changed to:
Looking at the code in mysql.cc you'll see that the first is an array of pointers to a function while the second is an array of pointers to StringTableEntries. Big difference. Returning the parentheses to where they belong worked wonders.
Good catch, Aron.
09/10/2011 (7:27 pm)
One of my team mates, Frederic Aron Riktor, found the problem. In line 392 of mysql.cc
return (*GetRow (_iResult))[_iField];
was changed to:
return *GetRow (_iResult)[_iField];
Looking at the code in mysql.cc you'll see that the first is an array of pointers to a function while the second is an array of pointers to StringTableEntries. Big difference. Returning the parentheses to where they belong worked wonders.
Good catch, Aron.
#10
Here is the corrected code for mysql.cc:
01/07/2012 (4:41 pm)
After upgrading to T3D 1.2 this problem reappeared even though what was done to fix the problem on 1.1b3 was in place. The function GetRow in line 392 of mysql.cc returns a pointer to a MYSQL_ROW struct defined in the MySQL library. This structure is an array of strings, one for each result returned by the query. Using a pointer here only works for the first string and will crash on the second string. The fix is to dereference the pointer returned by GetRow in a temporary variable.Here is the corrected code for mysql.cc:
StringTableEntry MySQL::GetRowCell (S32 _iResult, S32 _iField)
{
MYSQL_RES* pRes;
MySQLGetResultEx (pRes, 0);
// check position
if ((_iField< 0) || (_iField> mysql_num_fields (GetResult (_iResult))))
{
Con::errorf ("MySQL: invalid field index: %i", _iField);
return 0;
}
// get it
MYSQL_ROW* Row = GetRow(_iResult);
MYSQL_ROW aRow = *Row;
StringTableEntry myResult = (StringTableEntry)aRow[_iField];
if(myResult) return myResult;
else return 0;
}
Torque Owner A F
Default Studio Name
Compiles and runs fine for me and I can look at and edit fields in the database.
Did you use an express version of VS the last time you got it to compile?