A new core crash...

Has already been fixed, just hasn't pushed the newest Eluna revision to the main repo due to some experimental changes that comes with it as well.. Will be updated soon(ish)

Very well then, this is not a big concern of mine because I go for uptime anyway. I'll pull an update Friday and maybe we'll have it then. Once this is fixed I will close the ticket.

I just got this again when shutting down the server so I can build EvilDead's PR into it and test it.
[code]
Program received signal SIGSEGV, Segmentation fault.
0x08ad2cb0 in ElunaEventProcessor::~ElunaEventProcessor (this=0xaf391a90,
__in_chrg=)
at /home/---/zero/src/server/src/modules/Eluna/ElunaEventMgr.cpp:58
58 EventMgr::WriteGuard lock((*E)->eventMgr->GetLock());
[/code]
I will update the thread if it happens after this. If it goes away for a month, I will close it.

Still haven't had the chance to push the latest Eluna source, working on implementing temporary thread locking prior to multithreading, until then the shutdown crash will continue to happen unfortunately. Will update the issue once this is complete.

That's fine, no big rush. I only shut the server down once a week for updates anyway, unless we're testing something. I am only putting it here to keep the ticket from being buried and for future reference.

Just pushed an update to the latest stable release, Eluna shutdown crash should be fixed :) Please confirm and close accordingly!

Well considering I am stuck on that other PR, I will clone right now.

Bad news, I started the server, let it idle for ten minutes, then this.
[code]
server shutdown 30
CLI command under processing...
Table `command` overwrite for command 'honor show' default security (2) by 1
Table `command` overwrite for command 'modify honor' default security (1) by 2
Server is shutting down in 30 Second(s).
Command: server shutdown 30 [Account: 0 from Console]
mangos>Server is shutting down in 15 Second(s).
[Thread 0xb18f0b70 (LWP 3103) exited]
Network Thread Exitting
Network Thread Exitting
[Thread 0xb10efb70 (LWP 3104) exited]
[Thread 0xb08eeb70 (LWP 3105) exited]
[Thread 0xb20f1b70 (LWP 3102) exited]
[Thread 0xb6e4db70 (LWP 3095) exited]
[Thread 0xb765eb70 (LWP 3092) exited]
Halting process...
[Thread 0xb664cb70 (LWP 3098) exited]

Program received signal SIGSEGV, Segmentation fault.
0x08ad3c20 in ElunaEventProcessor::~ElunaEventProcessor (this=0xb4265a8,
__in_chrg=)
at /home/---/zero/src/server/src/modules/Eluna/ElunaEventMgr.cpp:58
58 EventMgr::WriteGuard lock((*E)->eventMgr->GetLock());
(gdb) backtrace
#0 0x08ad3c20 in ElunaEventProcessor::~ElunaEventProcessor (this=0xb4265a8,
__in_chrg=)
at /home/---/zero/src/server/src/modules/Eluna/ElunaEventMgr.cpp:58
#1 0x0867d3c4 in WorldObject::~WorldObject (this=0xb426048,
__in_chrg=)
at /home/---/zero/src/server/src/game/Object/Object.cpp:937
#2 0x08747aaa in GameObject::~GameObject (this=0xb426048,
__in_chrg=)
at /home/---/zero/src/server/src/game/Object/GameObject.cpp:80
#3 0x088c735d in Transport::~Transport (this=0xb426048,
__in_chrg=)
at /home/---/zero/src/server/src/game/WorldHandlers/Transports.h:34
#4 0x088c73b9 in Transport::~Transport (this=0xb426048,
__in_chrg=)
at /home/---/zero/src/server/src/game/WorldHandlers/Transports.h:34
#5 0x088f6bd4 in MapManager::~MapManager (this=0xb4387d8,
__in_chrg=)
at /home/---/zero/src/server/src/game/WorldHandlers/MapManager.cpp:53
#6 0x085caae8 in MaNGOS::OperatorNew::Destroy (obj=0xb4387d8)
at /home/---/zero/src/server/src/framework/Policies/CreationPolicy.h:59
#7 0x085caabf in MaNGOS::Singleton, MaNGOS::OperatorNew, MaNGOS::ObjectLifeTime >::DestroySingleton ()
at /home/---/zero/src/server/src/framework/Policies/Singleton.h:143
#8 0xb769122f in ?? () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#9 0xb769129f in exit () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#10 0xb7678e4e in __libc_start_main ()
from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#11 0x085bfbf1 in _start ()
[/code]
Appears to still be there.

Did you use clone or pull? If you pull you have to manually update the submodules as well :)

[COLOR=#444444][FONT=Consolas]git submodule update[/FONT][/COLOR]

I did not know that. I will do that now. Yes, I used pull.

Could you paste us the line 56 from your local ElunaEventMgr.cpp? (the if check)
FYI the line should look like this:
[url]https://github.com/ElunaLuaEngine/Eluna/blob/master/ElunaEventMgr.cpp#L56[/url]

The crash is caused by mangos destroying Transports on MapManager singleton destructor, which acts at the very end of the program after Eluna is uninitialized and the transport destructors try to access eluna.
To fix the crash the way/place where transports are destroyed needs to change or we can ignore the actions they try to do on eluna side.
In my opinion leaving cleanup for the singleton destructor isnt probably the best thing, unless its stricly singleton related data, which transports are not. (Transport = gameobject)

On the latest version the access attempts should be ignored avoiding the crash and it doesnt matter at that point anymore as the program is closing and the data is deleted already anyways.
However seems you are still getting the crash..

I just did as Reaper said and the old crash is gone. Now I have a new crash, related to the Eluna hooks, apparently.
[code]
server exit
CLI command under processing...
Table `command` overwrite for command 'honor show' default security (2) by 1
Table `command` overwrite for command 'modify honor' default security (1) by 2
Exiting daemon...
Command: server exit [Account: 0 from Console]
mangos>[Thread 0xb18f0b70 (LWP 4170) exited]
Network Thread Exitting
Network Thread Exitting
[Thread 0xb08eeb70 (LWP 4172) exited]
[Thread 0xb10efb70 (LWP 4171) exited]
[Thread 0xb20f1b70 (LWP 4169) exited]

Program received signal SIGSEGV, Segmentation fault.
0x08ab5799 in Eluna::OnShutdown (this=0x0)
at /home/---/zero/src/server/src/modules/Eluna/HookMgr.cpp:378
378 EVENT_BEGIN(ServerEventBindings, WORLD_EVENT_ON_SHUTDOWN, return);
(gdb) backtrace
#0 0x08ab5799 in Eluna::OnShutdown (this=0x0)
at /home/---/zero/src/server/src/modules/Eluna/HookMgr.cpp:378
#1 0x085c52a6 in Master::Run (this=0x8e46840)
at /home/---/zero/src/server/src/mangosd/Master.cpp:352
#2 0x085c4994 in main (argc=1, argv=0xbffff314)
at /home/---/zero/src/server/src/mangosd/Main.cpp:214
[/code]
Again, this happens on shutdown, not during gameplay, so it is not a major stopper. My only concern is if all of the data is being saved before a crash on shutdown.

Odd, not getting this on Win. Will test on Nix soon-ish.

I am using the old box for testing. It is running Debian Wheezy 32bit.

Are you using internal or external ace, out of curiosity

External. I always use external.

Figured as much, we found the issue and we're working on it :)

The issue was misplaced hooks.
However the crash was not noticed as an existing crash occurs before this one apparently when not using external ace ?

Fixed: [url]https://github.com/mangoszero/server/commit/8ade79aa394a8266178fd06e1dd7f5e933d2fae7[/url]

I'll rebuild shortly. What existing crash is happening?

The database thread is not able to exit cleanly on shutdown when using internal Ace. I just updated internal Ace from 6.1.4 to 6.3.0 and still having the same issue. Could you check what version external Ace uses on Linux by default? From my tests, Ace in and of itself isn't really to be blamed, but the database thread handling itself..

Wheezy has 6.0.3 backported. It is not a good idea to use the latest and greatest. The problem is that normal distros (not Gentoo) will sometimes be a year or two out due to stability. For example, when Wheezy was released, 5.x was stable, so they froze it there and offer security updates only for it. When Jessie (Debian 8, not out just yet) was frozen, it was at 6.0.3, so that was backported. If you get too far ahead with internal and do not use what major Linux distros use, you will eventually get far enough ahead that you will not be able to build MaNGOS under Linux. We REALLY need to choose a stable set of tools and use that version for a year, then upgrade, and repeat.

Anyway, 6.0.3 is the current STABLE version. If you like unstable Linux, you can get 6.2.8, but expect a broken OS from time to time. Most people run stable Debian/Ubuntu/Mint/whatever.

Hmm, according to ACE, their latest stable release is 6.3.0. That being said, I think I'm going to upgrade the internal to 6.3.0 and leave it at that for however long. We'll have to fix the issue with the database threadding at some point no matter, rather not postpone it by using an outdated Ace lib.

And what happens if it breaks on half the Linux distros? We need to stay off the bleeding edge of every library, or we need to stop using them and use C/C++ standards to get the job done. Remember, once anything from 6.3 is used that is not in 6.0, you break Debian and everything under, which is quite a bit. I am moving away from Debian due to systemd, but many users use Debian or Ubuntu.

Just built and ran ACE 6.3.0 on Ubuntu 14.04.1 LTS and everything seems to be working as intended. Threading starts as it should, core fires up and everything's all dandy. Will be running for a while to test, however as far as I can see, 6.3.0 should be working perfectly fine on this dist at least.

That being said, if 6.3.0 does not work on a distro, you can always use external ACE just like normal. This way we can start fixing bugs that happen with latter ACE versions, (ie. DB threading issue) and offer backwards compatibility for those not wanting to use bleeding edge, in this case external.

What I meant was, if you use a function introduced in 6.3, and a user has 6.0, they can no longer use external ACE, which is the better way to go in the Linux world. That was what I was getting at. I am not concerned as much since Gentoo is fairly bleeding edge itself. Heck, I am installing it on a laptop now. When I did my first Gentoo install a month ago I got kernel 3.16-5. This one pulled 3.17-7! Talk about speedy! I am just trying to make sure the project is available to as many users as possible. Maybe once the project is stable we can switch to using pure C++ for some of that stuff via the new boost types. It could REALLY reduce code, especially the cross-platform, cross-architecture variable types.