Migration from FC5 32-bit to Debian 64-bit
 

Making a thread to harvest suggestions. Any help is appreciated. :)

Original system is a 32-bit Fedora Core 5 box. New system is a 64-bit Debian install. It's an Intel Core2Duo running kernel 2.6.18-6-amd64, x86_64.

Our code is somewhat custom but primarily the same as project-eqemu trunk, last changelog March 23rd 09.

Old gcc version is 4.1.2 (20070502), new gcc version is gcc 4.1.2 (20061115, prerelease, fair enough debian is cautious).

We brought our source tree over to the new machine and immediately tackled these issues:

- Had to modify common/TCPConnection.cpp to force addrlen variable to type of socklen_t* instead of size_t*

- Modifying makefiles to use -march=nocona instead of -march=i686, removed compile flags -DI386. ( gcc <= 4.3 doesn't have the core2 arch and nocona was suggested here )




Behavior:

./zone - Segfaults.
GDB:
Juicy bit in frame #2, EQEMuLog::write():160
Segfault in vprintf(), doh. This bug report for Debian suggests:
However, debug.cpp where EQEMuLog::write() is located already includes string.h (line 6).

Going ahead and posting this for assistance, but still researching the issue with vprintf and whatnot. Might be a dead-end or not, we'll see.

Thanks for any help, all.

He forgot to say

HEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEELP !!!!!!!!!!!!!!!!!!!!!!

So there I said it...

There is a patch in the last post of this thread that may help you:

http://www.projecteq.net/phpBB2/view...ghlight=valist

I've not tried to compile on 64-Bit Linux myself.

That's gotten zone to boot and supporting players (at least one) so far. Thanks so much.

For future reference, the link posted above contains a diff of common/MiscFunctions.cpp and common/debug.cpp, copied below:

Thanks gaeorn for posting your fix.

Continuing on...

Zone is now crashing on ZoneDatabase::LoadAAs()

Zone init appears normal and happy:

However upon hitting "Enter World" we get a spam of errors like the following:

ultimately followed by

Backtrace has:

Poking through it myself at the moment.

Have you tried a vanilla installation? eg: a PEQ DB and an appropriate version of EQEmu code. This could show you if you have an underlying problem with the system or if the problem is in your custom code.

I know that PEQ DB 1129Rev535 and EQEmu instance branch rev 585 works for me. I'm using Fedora 8 x86_64 on a Pentium D. I did not set -march at all during compile time.

Had to do actual work for awhile :(

Went down into GetAASkillVars() and found that it isn't returning rows. Query is at line 1310 roughly, next if() block checks row count and fails at 0. skill_id is apparently '2', Innate Strength.

Running the actual query on the database from the mysql CLI client produces the expected results:

errbuf is empty, result.fields is populated with the expected field names. Not sure why it's not matching anything... I might not have the mysql libs linked in properly... Gonna have to take a look at it again in awhile.

I also modified my zone makefile:

Since under Fedora, the 64 bit libs are in within different paths (lib64 rather than lib), I had to make that change. I can't remember if Debian does this or not. In any case, the above should give the proper compile and linking flags for mysql.

I pulled a clean trunk down from the googlecode svn. Made the changes above, including modifying the makefiles.

Unfortunately the server still crashed on LoadAAs().

Pulled down a fresh version of PEQ and got it updated. Our custom bins can get into zone without a crash with the fresh PEQ db.

Gonna double-check our dump and ensure everything came down properly.

Well, at least you have narrowed down the problem. Let me know if there is anything else you need.

Yup just something whacked out with that particular copy of the database...