When performing stop/restart on r274 MCS responds with:
...
[<time>] TICK THREAD STOPPED
And then nothing else happens...
...
[<time>] TICK THREAD STOPPED
And then nothing else happens...
[FIXED] r279 - stop/restart doesn't work
|
When performing stop/restart on r274 MCS responds with:
... [<time>] TICK THREAD STOPPED And then nothing else happens...
02-17-2012, 05:21 AM
Are you on windows or on linux? Can you work with your platform's debugger? Can you inspect the process to see where the individual threads are blocked?
02-17-2012, 05:59 PM
I'm on Linux. I'm not very familiar with debugging but I'm guessing I should use gdb. Can you guide me further?
Well, Linux is the difficult one for me, but i'll try. I have only experience with ubuntu server, so your distro might differ.
First compile MCServer in the debug mode (default for the GNUmakefile; "make clean" before switching; instructions are in the COMPILING file). Then get MCServer to the situation that you describe - deadlocked while stopping. Then on another console: 1, Find out the MCServer PID, using "ps uxaw | grep MCS". It should list the processes containing MCS in their cmdline, so find the MCServer one and the PID is the number in the second column. 2, Start gdb with parameters path-to-MCServer PID ("gdb ./MCServer 8093"). GDB spits out a few lines of info, "Reading symbols from ~/MCServer...done." should be one of them. If it says "(no debugging symbols found)" in the MCServer line, then you didn't compile for debugging - retry (you need to make clean) 3, GDB now is waiting for your commands. Try "info threads" first to see all the threads; normally MCServer uses 5 - 7 threads. 4, For each thread in the table, use two commands, first "thread N" (where N is the thread number, first in the table), then "bt". This should print out a table of where the thread is executing. 5, Post all the output here, I'll have a look. For me, this is what I get: Code: (gdb) info threads 6, To quit gdb, use "q" command; it will ask if it's okay to detach from the MCServer process, answer "y".
Here's some output from gdb on r279. I had to log output to a file (set logging on) which doesn't show the commands given. I hope you can use it anyways..
Code: Id Target Id Frame When the debug session ended MCS wrote the following (this wasn't shown earlier): [...] [11:55:06] TICK THREAD STOPPED [11:56:10] Waiting for the world storage to finish saving [11:56:10] --- Stopped Log ---
02-17-2012, 09:01 PM
Seems more or less the same as mine. I't waiting for the webserver to finish, and for some reason the webserver doesn't take the hint. Thanks for the dump, I'll see if I can do anything about it.
02-17-2012, 11:11 PM
I think I found it. On linux, just closing a socket filedescriptor in one thread doesn't wake up the thread blocked on an accept() or select() for the same socket. The fix is to call shutdown for that socket fd before closing.
Fixed in rev 283.
Yeah it's fixed!
I've tried stress-testing the restart-command using the following command line (on Linux): echo restart | ./MCServer Output from MCS shows that the restart command is executed succesfully. But it also goes into an endless loop outputting the following several times a sec: [12:31:10] Server console command: "" At the same time memory consumption rises. I don't think this is an important bug to fix but because of the memory consumption I thought you should know.... EDIT: I just tried the same with r235 and there was no endless loop. The above observation could be related to the implemented multithreading... |
« Next Oldest | Next Newest »
|