30 Nov, 2009, quixadhal wrote in the 21st comment:
Votes: 0
If nothing shows up, then either your control socket isn't working properly (IE: signals aren't working right, or the socket itself didn't bind properly), or your client isn't able to connect to your local server. Since you've tested other muds by compiling them in the same environment, and had success, that isn't likely.

Unfortunately, if it IS that kind of issue, the only thing you can really do is compare your code against a known working equivalent to try and spot anything unusual… fcntl() calls with obscure options, stuff like that.

If it hits there, then you know the problem lies further down and can continue leaving breadcrumbs. :)
01 Dec, 2009, Tyche wrote in the 22nd comment:
Votes: 0
Elervan said:
I'd love to give you all more information from gdb. However, I get nothing from it. And I'm not familiar with adding debugging and break points into the code to give more information. I just know bt comes back with nothing. The last thing I see in gdb is this:

Mon Nov 30 16:39:38 2009 :: boot_db() - wrote exodus.pid
Mon Nov 30 16:39:38 2009 :: Exodus is ready to rock on port 4000.



Now if I ctrl + c to get back to the command prompt in gdb and do a bt I get this:
#0 0x7c8106f9 in KERNEL32!CreateThread ()
from /cygdrive/c/WINDOWS/system32/kernel32.dll
Cannot access memory at address 0x3


Well that's the normal result of CTL-C under cygwin.
You need to learn to set breakpoints and step through the code in gdb.
Otherwise you're SOL. ;-)
01 Dec, 2009, Tyche wrote in the 23rd comment:
Votes: 0
if (select (fdsize, &in_set, &out_set, NULL, NULL) < 0) {

That's most certainly wrong as it will block indefinitely. At least from ROM's design standpoint.
It will cause your mud to lock up and never execute any update routines unless someone actually enters input or connects.

Where do you update fdsize?
I strongly suspect you're not keeping track of the correct number of FDs, so select ain't working correctly.

BTW, This code looks broken on any system.
01 Dec, 2009, Mabus wrote in the 24th comment:
Votes: 0
Are you able to telnet into the server from within the Cygwin shell?

telnet localhost <port #>

Example:
telnet localhost 4000

If you are able to telnet in from within the Cygwin shell then it may be port forwarding, firewall or other issues.

Been a while (I useAndLinux now) but I seem to remember Cygwin uses port 6000 for input/output traffic. For the IP address using ipconfig /all in a windows command window should show the assigned address.

I know this may be overly simplistic, and you may have already checked/known about these things, but best to start from the beginning.
01 Dec, 2009, Elervan wrote in the 25th comment:
Votes: 0
The client connects but doesn't do anything (no greeting comes up) so its hanging somewhere. I'm going through the signal handling stuff comparing this to a stock rom which works.
01 Dec, 2009, Tyche wrote in the 26th comment:
Votes: 0
Elervan said:
The client connects but doesn't do anything (no greeting comes up) so its hanging somewhere. I'm going through the signal handling stuff comparing this to a stock rom which works.


You are wasting your time.
I've already nailed your problem.
Listen to Tyche.
I am psychic zen master of debugging.
01 Dec, 2009, David Haley wrote in the 27th comment:
Votes: 0
I agree with Tyche – you really need to make sure that fdsize is being updated correctly. It so happens, by the way, that Winsock and *nix implementations treat this parameter differently, so this would also explain why the code works on some OSs but not on others.
EDIT: And, of course, you need to make the select statement time out so that updates etc. are processed even when there is no player activity.
01 Dec, 2009, Tyche wrote in the 28th comment:
Votes: 0
David Haley said:
Winsock and *nix implementations treat this parameter differently, so this would also explain why the code works on some OSs but not on others.


Cygwin treats the parameter exactly like Posix requires, not like Windows. It has nothing directly to do with Windows. This code would fail to run on many Unixes. The problem is that the returned FD from accept or socket is not guaranteed by Posix to be predictable, only a positive integer. That's why the original ROM code tests each of the FDs it's placing in the FD_SETs to make sure it enters the largest of them + 1.

All that code appears to have been commented out, in favor of some assumption somewhere about fdsize. We don't know what because the poster ain't saying, so we need to use psychic debugging. ;-)
01 Dec, 2009, Elervan wrote in the 29th comment:
Votes: 0
Hey,

Doing what Tyche suggested I uncommented the maxdesc and &exc stuff that was commented out and changed that one line to match ROM's and it works fine.

About fdsize, I find 2 other spots using it. I'll post the start and end of that code, Not very long as it is mostly int main() that is calling it.

int fdsize;

//
// Akamai 01/24/00 - This function writes the process id of the Exodus
// main code to a file. Useful for special shutdown scripts.
//

// prototype
void exodus_pid ();

// function
void exodus_pid () {
char buf[MAX_INPUT_LENGTH];
char pidf[MAX_INPUT_LENGTH];
FILE *fp;
long pid = 0;
pid = (long) getpid ();

// sprintf(buf,"Exodus PID: %ld",pid);
sprintf (buf, "%ld", pid);
sprintf (pidf, "%s%s", BIN_DIR, EXODUS_PID);
if ((fp = fopen (pidf, "w")) != NULL) {
fprintf (fp, "%s", buf);
fclose (fp);
log_string ("boot_db() - wrote exodus.pid");
// log_string (buf);
} else {
bug ("Couldn't open exodus.pid file.", 0);
log_string (buf);
}
}

int main (int argc, char **argv) {
struct rlimit fd_limit;

//, stack_limit;
struct timeval now_time;
int port;
int control, whosock, areasock;

#if defined(MALLOC_DEBUG)

malloc_debug (2);

#endif /* */

init_signals (); /* For the use of the signal handler */
gettimeofday (&now_time, NULL);
current_time = (time_t) now_time.tv_sec;
strcpy (str_boot_time, ctime (&current_time));
getrlimit (RLIMIT_NOFILE, &fd_limit);
fd_limit.rlim_cur = fd_limit.rlim_max - 8;
setrlimit (RLIMIT_NOFILE, &fd_limit);
@@ fdsize = fd_limit.rlim_cur;

// Shinowlan - debug attempt to fix 'save' recurse problem
// this, in general, does not work. So it's commented out.
/*
getrlimit(RLIMIT_STACK, &stack_limit);
log_buf[0]= '\0';
sprintf (log_buf, "STACK: intially at %ld bytes.", stack_limit.rlim_cur);
log_string(log_buf);
stack_limit.rlim_cur = stack_limit.rlim_max;
setrlimit(RLIMIT_STACK, &stack_limit);

log_buf[0]= '\0';
sprintf (log_buf, "STACK: Current stack is now set to %ld bytes", stack_limit.rlim_max);
log_string(log_buf);

getrlimit(RLIMIT_STACK, &stack_limit);
log_buf[0]= '\0';
sprintf (log_buf, "STACK: is at %ld bytes.", stack_limit.rlim_cur);
*/
if ((fpReserve = fopen (NULL_FILE, "r")) == NULL) {
perror (NULL_FILE);
exit (1);
}
port = 9000;
if (argc > 1) {
if (!is_number (argv[1])) {
fprintf (stderr, "Usage: %s [port #]\n", argv[0]);
exit (1);
} else if ((port = atoi (argv[1])) <= 1024) {
fprintf (stderr, "Port number must be above 1024.\n");
exit (1);
}
}
#if defined(unix)
if (port == 9000) {
whosock = init_socket (8999);
areasock = init_socket (8887);
} else {
whosock = -1;
areasock = -1;
}
control = init_socket (port);
boot_db ();
sprintf (log_buf, "Exodus is ready to rock on port %d.", port);

/*
signal (SIGUSR1, machine_reboot);
signal (SIGTERM, machine_reboot);
*/
exodus_pid ();
log_string (log_buf);
game_loop_unix (control, whosock, areasock);
close (control);

#endif /* */

log_string ("Normal termination of game.");
exit (0);
return 0;
}


Is that why fdsize is being used in game_loop_unix?
01 Dec, 2009, Tyche wrote in the 30th comment:
Votes: 0
The code doesn't handle RLIM_INFINITY. So it sets fdsize to a negative number.
Regardless the first parameter of select should be the largest actual fd in use + 1.
The code would happen to work under a shell that has a file limit set.
20.0/30