Clients Cant connect to DreamDaemon on Debian Wheezy

ID:1335122
 
Jul 26 2013, 1:20 am
My friend asked me to set up a SpaceStation13 server for him on a vps I have. He sent me this link http://wiki.nanotrasen.com/ index.php?title=Downloading_the_source_code

I set everything up launched the server and everything seems to be fine. Except no one can connect to the server. The client just says your game is starting, connecting and nothing happens.

It is definitely not a network configuration error. I can connect to netcat listening on the game port perfectly fine and netstat shows me the client connected to the port. Any ideas would be appreciated!

byond@games:~$ DreamDaemon tgstation/tgstation.dmb -safe
Fri Jul 26 07:08:46 2013
World opened on network port 1337.
Welcome BYOND! (4.0 Public Version 499.1201)
Running /tg/ revision number: 2674de5ec4fde5a1b9dea98732f7813cdf54fab8.



necronian@games:~$ netstat
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp       18      0 games.uberpurple.c:1337 c-68-37-192-13.hsd:3622 ESTABLISHED
Jul 26 2013, 1:26 am
I suppose it's worth asking, does the game have any required pre-requisites (such as a database, which I see the wiki references) before it will allow players to complete client/New() properly?
Jul 26 2013, 1:37 am
I forgot to mention, through the course of debugging I booted into windows on my local machine and grabbed the source code, compiled it and ran it with the windows version of dreamdaemon and it worked no problem locally. I then copied that compiled code to the server and tried hosting it and still had the same issue. So I don't think there are any issues with that.
Jul 26 2013, 1:46 am
How much CPU is that process using?
Jul 26 2013, 1:54 am
It is using a lot.

top - 07:53:28 up 50 min,  1 user,  load average: 0.22, 0.05, 0.08
Tasks:  24 total,   2 running,  22 sleeping,   0 stopped,   0 zombie
%Cpu(s): 23.6 us,  0.0 sy,  0.0 ni, 75.2 id,  0.0 wa,  0.0 hi,  0.0 si,  1.2 st
KiB Mem:   2621440 total,   254480 used,  2366960 free,        0 buffers
KiB Swap:        0 total,        0 used,        0 free,   115820 cached

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
 1844 byond     20   0  124m 121m 2648 R  94.9  4.7   0:11.59 DreamDaemon
Jul 26 2013, 1:57 am
Is it reporting on the hub as being available at the moment, or printing anything out to logs?
Jul 26 2013, 2:01 am
No to either. The only output that I see is what is returned after I start dreamdaemon I posted in the first post. As far as I can tell there isn't any other logging? Unless I give it the -selflog or -log options which just redirects the stout/stderr to a file?
Jul 26 2013, 2:13 am
Right. What version of BYOND is this hosted on, and compiled with?
Jul 26 2013, 2:18 am
Version 499.1201 I compiled it on the linux server originally using DreamMaker on linux. But now I'm trying to run the code I compiled using the same version of the windows tools that I uploaded after I saw it was working on windows. Both versions have the same exact issue.
Jul 26 2013, 2:24 am
Can you add te -logself to the DreamDaemon command this will create a log file gamename.log for you.

Also I haven't had much lucky with 1201 see - http://www.byond.com/ forum/?post=1264881&page=4#comment5726189 - which was only a few hours or so after upgrading BYOND.

One issue I have with your original post is that it doesn't mention if its accessible by the hub or not which is strange, logself should help you there.

Apart for that try installing 1158 or 1197 you can install it over the top that's fine.

[EDIT] download link for all 499'version - http://www.byond.com/download/build/499
Jul 26 2013, 2:31 am
I downgraded to 499.1200 and it appears to be working! Thank you. Is there somewhere I should be reporting bugs?
Jul 26 2013, 2:34 am
http://www.byond.com/forum/?forum=5 There is usually the best place. It may be part of the ongoing 'linux freeze' issue, I suppose. It's been very variable per-game as to the circumstances that cause it.
Jul 26 2013, 2:38 am
As Stephen said! I am not sure that I agree on the per game bit though, I really have a feeling it's either backwards compatibility per BYOND client and perhaps the hub thats messing things up, i not a developer of BYOND so I am not sure but here's the post - http://www.byond.com/forum/?post=1264881
Jul 26 2013, 2:41 am
If you can add any concrete logs to that post that'll be great, it's really frustrating though..
Jul 26 2013, 2:47 am
Well, I have about ... 3 or 4 servers on 499.xxx that are happy, but some that die out with this problem hosted on 498.xxx when compiled with 499.xxx
Jul 26 2013, 2:51 am
I don't think I'm going to post anything in the bug report forum. There isn't much I can add that isn't in this thread now. I don't really know what the problem was, just that version 499.1201 doesn't work for me. The log has the exact same output as is the output of the DreamDaemon command in my first post except now the line 
The BYOND hub reports that port 1337 is reachable.
is added. I feel like posting would just be a bit of a waste and everything is documented here.
Jul 26 2013, 2:53 am
In response to Stephen001
The same ref count issue?

I really hope they can diagnose the issue, I do understand its hard without proper evidence but that post has an awful lot of issues from various games / versions.

I can confirm that 498 * was the most stable and a lot of my servers are still on 498 *

WANO (Chance) wants to upgrade to the latest I don't blame him for that choice as I do it often with all my program's...
Jul 26 2013, 2:57 am
In response to Necronian
That was the first time I tried 1201 obviously it failed and failed fast, I think any type of report is a good report I would really appreciate it of you did post the log that has errors along with the game name at least on that post it'll just help the developers a bit more.

It would also be nice to post what version of BYOND the game was compiled with, if that's possible!
Jul 26 2013, 3:01 am
It's kind of unrelated to the refcount stuff itself (but the refcount may be one of the triggers into the code-path in question). From a debug session, Lummox and myself had basically deduced a tree data structure used for searching strings had gotten itself into an infinite loop, and so the code could not progress. The chain of events for this to happen is potentially quite long, and may have even happened in a different proc execution to the one you get stuck in, which makes it a PITA to debug via gdb.


Lummox's suspicion is that it's a heap corruption issue, so running under valgrind memcheck would catch any iffy pointer use that might cause such a heap corruption. As BYOND uses a lot of pointers to uninitialised memory, you'll get a lot of spurious messages out too. The important bit is what happens when you end the application though, and it provides it's summary report.