Another Scripting bug ?...

Forwarding this to Rochet, will have him take a look at it :D Definitely seems to be Eluna related. Thanks for the report!

I think the issue might be that transport unloads after eluna unloads, causing the crash.
[code] mangosd.exe!ElunaEventProcessor::~ElunaEventProcessor() Line 55 + 0x3 bytes C++
mangosd.exe!ElunaEventProcessor::`scalar deleting destructor'() + 0x16 bytes C++
mangosd.exe!WorldObject::~WorldObject() Line 937 + 0x1f bytes C++
mangosd.exe!GameObject::~GameObject() Line 87 + 0x57 bytes C++
mangosd.exe!Transport::~Transport() + 0x4e bytes C++
mangosd.exe!Transport::`scalar deleting destructor'() + 0x16 bytes C++
[B] mangosd.exe!MapManager::~MapManager() Line 53 + 0x29 bytes C++
mangosd.exe!MapManager::`scalar deleting destructor'() + 0x16 bytes C++
mangosd.exe!MaNGOS::OperatorNew::Destroy(MapManager * obj) Line 59 + 0x1c bytes C++[/B]
mangosd.exe!MaNGOS::Singleton,MaNGOS::OperatorNew,MaNGOS::ObjectLifeTime >::DestroySingleton() Line 143 + 0xb bytes C++
msvcr120d.dll!0fc3edf3()
[Frames below may be incorrect and/or missing, no symbols loaded for msvcr120d.dll]
msvcr120d.dll!0fc3eea0()
mangosd.exe!__tmainCRTStartup() Line 662 C
mangosd.exe!mainCRTStartup() Line 466 C
kernel32.dll!76b4338a()
ntdll.dll!77199f72()
ntdll.dll!77199f45() [/code]

Seems that transports are not unloaded on mapmgr unloadall. The transports unload when the MapMgr singleton gets destroyed when the program shuts down.
We could fix this on Eluna side by just checking if Eluna still exists at that point.
Or the fix could be that transports are unloaded when everything else is unloaded.
Not sure leaving any actual object data to be destroyed in the end of whole program should be done.
What do you think? : /

In addition to the transports being a problem, the BG data is also a problem as it also gets deleted only at the very end and not when for example maps unload

Ill make a PR that will remove the crash, but the unload handling should still be discussed.
[url]https://github.com/mangoszero/server/pull/238[/url]

I imagine the transport is not unloaded for some reason like, if the grid is unloaded, the transport still needs to stay on schedule. If not, I do not see why it is unloaded after the grid.

A temporary fix has been pushed, however we suggest going through and restructuring the unload process to be more clear as to what unloads when.

I agree. If the transports do not need to remain loaded, they should probably be unloaded with everything else. I would like to understand why they're not unloaded before we change it, however. Does anybody know why this is configured like this?

I wanted to update this issue. Eluna caused a new crash just now during shutdown.
[code]
Program received signal SIGSEGV, Segmentation fault.
0x08551fa3 in Eluna::OnShutdown (this=0x0)
at /home/---/zero/src/server/src/game/LuaEngine/HookMgr.cpp:367
367 EVENT_BEGIN(ServerEventBindings, WORLD_EVENT_ON_SHUTDOWN, return);
(gdb) backtrace
#0 0x08551fa3 in Eluna::OnShutdown (this=0x0)
at /home/---/zero/src/server/src/game/LuaEngine/HookMgr.cpp:367
#1 0x08547b16 in Master::Run (this=0x8c9a7d0)
at /home/---/zero/src/server/src/mangosd/Master.cpp:352
#2 0x08547204 in main (argc=1, argv=0xbffff314)
at /home/---/zero/src/server/src/mangosd/Main.cpp:214
[/code]
The code at #0 is the crash.

Passing it along to Rochet ;) This may or may not have to wait till the upcomming SD2 and cmake rewrite :)

Hmm.
The uninit order is correct.
I cant find a logical reason or a way to reproduce this. Eluna is not deleted at any point before that.

~Linux only?

I never run ANY server process on Windows. I do have a 2008 R2 license somewhere, but I'd need hardware to plop it onto. so yes, this is Linux, but I cannot test Windows.

[quote=Xenithar]I never run ANY server process on Windows. I do have a 2008 R2 license somewhere, but I'd need hardware to plop it onto. so yes, this is Linux, but I cannot test Windows.[/quote]
But is it reproducable? How?
I tested on windows and could not reproduce.

Yes, sorry. I can reproduce it by starting my server, idling for five minutes, then doing "server shutdown 10". Ten seconds later it begins to go down and crashes.

Fresh clone and build from scratch today. Here you go.
[code]
mangos>server shutdown 10
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 10 Second(s).
Command: server shutdown 10 [Account: 0 from Console]
mangos>[Thread 0xb18f2b70 (LWP 10992) exited]
Network Thread Exitting
Network Thread Exitting
[Thread 0xb08f0b70 (LWP 10994) exited]
[Thread 0xb10f1b70 (LWP 10993) exited]
[Thread 0xb20f3b70 (LWP 10991) exited]

Program received signal SIGSEGV, Segmentation fault.
0x08551fa3 in Eluna::OnShutdown (this=0x0)
at /home/---/zero/src/server/src/game/LuaEngine/HookMgr.cpp:367
367 EVENT_BEGIN(ServerEventBindings, WORLD_EVENT_ON_SHUTDOWN, return);
(gdb) backtrace
#0 0x08551fa3 in Eluna::OnShutdown (this=0x0)
at /home/---/zero/src/server/src/game/LuaEngine/HookMgr.cpp:367
#1 0x08547b16 in Master::Run (this=0x8c9a7d0)
at /home/---/zero/src/server/src/mangosd/Master.cpp:352
#2 0x08547204 in main (argc=1, argv=0xbffff314)
at /home/---/zero/src/server/src/mangosd/Main.cpp:214
[/code]
Still happens under 32bit Linux. Have not tested on 64bit Linux.

Odd, but as of today, the normal shutdown command works (server shutdown ), but using "server exit" crashes with the Eluna error above.

Does this still happen ?

I will try this evening. I can tell you that the timed shutdown command causes a broken pipe EVERY TIME for the last two weeks. I will test all shutdown commands tonight on Linux.

Broken pipe is related to MySQL shutdown routine with the new Ace lib. Trinity fixed this years ago, however our database code is so different to theirs that it makes it hard to pinpoint exactly what should be changed. The commit is also marked unstable.

Googling the error points you directly to the TC issue tracker.

Alright, I have a ticket open about the broken pipe, so we can worry with it there. I will be testing server shutdowns shortly.

Still happens.

Command: server shutdown 10
[code]
Aura 17 now is remove mode 5
[Thread 0xb20f1b70 (LWP 5809) exited]
[Thread 0xb6e4db70 (LWP 5805) exited]
[Thread 0xb765eb70 (LWP 5804) exited]
Halting process...
[Thread 0xb664cb70 (LWP 5806) exited]

Program received signal SIGPIPE, Broken pipe.
0xb7fe1424 in __kernel_vsyscall ()
(gdb) backtrace
#0 0xb7fe1424 in __kernel_vsyscall ()
#1 0xb77d42eb in write () from /lib/i386-linux-gnu/i686/cmov/libpthread.so.0
#2 0xb7b7cead in vio_write ()
from /usr/lib/i386-linux-gnu/libmysqlclient.so.18
#3 0xb7b6b00e in net_real_write ()
from /usr/lib/i386-linux-gnu/libmysqlclient.so.18
#4 0xb7b6b268 in net_flush ()
from /usr/lib/i386-linux-gnu/libmysqlclient.so.18
#5 0xb7b6b580 in net_write_command ()
from /usr/lib/i386-linux-gnu/libmysqlclient.so.18
#6 0xb7b68598 in cli_advanced_command ()
from /usr/lib/i386-linux-gnu/libmysqlclient.so.18
#7 0xb7b65381 in mysql_close ()
from /usr/lib/i386-linux-gnu/libmysqlclient.so.18
#8 0x08978d3b in MySQLConnection::~MySQLConnection (this=0xafded70,
__in_chrg=)
at /home/---/zero/src/server/src/shared/Database/DatabaseMysql.cpp:80
#9 0x08978d8d in MySQLConnection::~MySQLConnection (this=0xafded70,
__in_chrg=)
at /home/---/zero/src/server/src/shared/Database/DatabaseMysql.cpp:81
#10 0x0897379a in Database::StopServer (this=0x8df92e0)
at /home/---/zero/src/server/src/shared/Database/Database.cpp:158
#11 0x08978c4f in DatabaseMysql::~DatabaseMysql (this=0x8df92e0,
__in_chrg=)
at /home/---/zero/src/server/src/shared/Database/DatabaseMysql.cpp:65
#12 0xb769122f in ?? () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#13 0xb769129f in exit () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#14 0xb7678e4e in __libc_start_main ()
from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#15 0x085ac9d1 in _start ()
[/code]

Command: server exit
[code]
mangos>server exit
CLI command under processing...
Exiting daemon...
Command: server exit [Account: 0 from Console]
mangos>[Thread 0xb18f0b70 (LWP 24678) exited]
Network Thread Exitting
Network Thread Exitting
[Thread 0xb10efb70 (LWP 24679) exited]
[Thread 0xb08eeb70 (LWP 24680) exited]
[Thread 0xb20f1b70 (LWP 24677) exited]
[Thread 0xb6e4db70 (LWP 24674) exited]
[Thread 0xb765eb70 (LWP 24673) exited]
Halting process...
[Thread 0xb664cb70 (LWP 24675) exited]
[Inferior 1 (process 24671) exited normally]
[/code]
This seems to be normal now. Using exit works, using shutdown fails. I would think that "server shutdown " would wait X seconds and then simply call whatever method exit calls. Apparently this is not the case.

Is this still a issue after the recent changes ?

Antz I am not sure. My RAID array had that bad disk (see my forum thread) and I won't even know if WD will replace the BRAND NEW disk until Tuesday. Once I get my disk I can install XenServer and get my systems back online.

Cannot reproduce at current Zero version, even issuing the command from within the client. It means that the problem is either fixed, or appears at random depending on the moment the timer expires. For the latter case, should be tested at considerable online, like 100.

This issue has already been fixed :)