UCS and Queryserv: Segmentation Fault
I recently updated mariadb via
Code:
apt-get dist-upgrade Code:
./server_start.sh Code:
[Status] Loading items... Code:
World: UP Zones: (30/30) UCS: DOWN Queryserv: DOWN If I try to run Code:
sudo ./ucs Code:
[UCS Server] Starting EQEmu Universal Chat Server. Code:
sudo ./queryserv Code:
[QS Server] Starting EQEmu QueryServ. Code:
{ I'm quite confused what to do next... the server was up and running fine yesterday before the update. Anyone have any ideas how to troubleshoot this? |
Some more info using gdb:
Code:
sudo gdb ucs Code:
sudo gdb queryserv |
So I've now completely wiped and reinstalled mysql-server:
Code:
sudo apt purge mysql-server mysql-client mysql-common I can run shared_memory, world, eqlaunch, and zone without any errors. It's still only ucs and queryserv that give the Segmentation fault errors. If I launch everything except ucs and queryserv, I am able to get to the character creation screen. Trying to zone in, however, gives me the error: Code:
[World Server] No zoneserver available to boot up. |
Some more information from journalctl -xe:
Code:
kernel: traps: ucs[1394] general protection ip:7fab0f107676 sp:7fffed51fd38 error:0 Code:
==6770== Command: ./ucs |
I haven't been ignoring this thread..I just don't have any linux experience...
For 'ucs' and 'queryserv' servers, they do not affect the server's ability to operate. That logging error, however... That would definitely cause a problem. I'll take a look at that call and see if I can find anything. |
No problem, I am definitely out of my league on this one! UCS and Queryserv are still giving the segmentation fault, but I have been able to get the serving running without them for now. I essentially purged and reinstalled mysql-server and all of the dependencies in install.sh, deleted the old database and eqemu user in mysql, deleted and recreated the eqemu account, restarted my machine, and then reran install.sh to make the binaries. Now the server runs and I can connect to it, and everything on the client side seems to work fine. I'm not sure if there are bigger problems lurking underneath though, with logging for example, like you mention...
|
What happens if you change the host entries in your config to localhost?
|
Unfortunately, changing the host entries to "localhost" didn't seem to have an effect... still getting the Segmentation fault :/
|
In windows, "localhost" will always resolve into tcp/ip (127.0.0.1), but that is not always the case in linux, it can do crazy things, like trying to resolve into an IPv6 address, but either way, not sure why people are so adamant about using that infamous localhost. Using 127.0.0.1 in all the configs, will guarantee to rule out that cause, for anything local.
|
Debugging it done, the error is actually in eqemu_logsys.cpp in platform_file_name.c_str(). "ucs" is definitely in platform_file_name but somehow c_str is causing a segmentation fault. I am rusty on my C++ at the moment but I will get a resolution.
At some point platform_file_name is getting assigned the value of ucs, but at the time LogSys.StartFileLogs() is ran at ucs.cpp on line 101, that value does not appear to be there, at least on the surface. When we get to eqemu_logsys.cpp line 462 it throws a segmentation fault, my best guess is there is a null there. I am still reading on proper use of c_str but on the surface I guess there is a null there. There is a check for empty but it seems to blow past that. |
I'm pretty sure my_string.c_str() should return a nullstring pointer even if my_string.empty() is true.
Variadics on the other hand... If you pass a nullptr argument, add too many formatizers or too few arguments, it will crash. |
Right, I did have a little while to read more about c_str(). Apparently it cannot be null, it can have a null pointer but std::string cannot actually ever be null, there should always be a value even if it is an empty string. Also from reading there can still be quite a few bad things happen to cause std::string to go haywire and I guess that is what is happening. It definitely gets assigned a value at some point because I see the value appear but later on something happens. I have yet to find what is happening. Maybe I can look at it again tomorrow.
|
I had some time this morning to look at it again. I never would had figured the bug was in this location.
In the directory for ucs and queryserver look at the database.cpp and you will notice my correction here. One thing is that the routine was overwriting the file log settings every iteration, because it always ran through every entry without stopping. So really the routine was not really working properly without this being adding. I am not getting the segmentation fault anymore and my log is being written so I guess it is working? I need someone with a higher pay grade to look over this change though. Code:
for (auto row = results.begin(); row != results.end(); ++row) { |
Interesting, just seeing this thread for the first time. I'll put it on my list to check this one out tonight
|
First look this is related to newer GCC versions, investigating closer
|
All times are GMT -4. The time now is 12:50 PM. |
Powered by vBulletin®, Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.