Cygwin Erorr.. Connection

Posted by AliasCodec on Fri 13 Jan 2006 12:07 AM — 28 posts, 101,189 views.

AliasCodec USA Fri 13 Jan 2006 12:07 AM #0

Ok.. I have been looking for a while and cannot for the life of me find anything on the web about this, only vague references and no answers.

About a year ago I ran my ROM MUD with no problems using Cygwin. But now, with the new Cygwin, I am unable to recieve any connections. Here's what happens..

I start up Cygwin and go to my area folder as usual. Out of habit I run in gdb and specify my port just for safety. It get's up and running, then I go to log in.. that is where the issue occurs. It is programmed in the MUD to send a string when a connection is attempted, but nothing happens. My telnet client says connected to localhost (what I use instead of 127.0.0.1 or my network IP) then after 5 seconds it disconnects. Cygwin never recognizes that it connected.

In all honesty, I cannot say that this is purely a Cygwin problem. I am also unable to get Ventrilo Server running and connectable. Currently running WINXP SP2, so if anyone has experienced this before, I would greatly appreciate any help. I have disabled the firewall, all router firewalls, set up all port forwarding, yet nothing is working for the incoming connections, not even when I try and connect from my own computer, the server.

Zeno USA Fri 13 Jan 2006 12:26 AM #1

If your logfile never sees you connect, then something is wrong. Make sure you're connecting to the right port. Another thing I would say to try is running another MUD codebase to see if that works. Something that works fine under Cygwin such as SmaugFUSS.

I don't think a firewall would block you from connecting to localhost. I've never had that problem. Test to make sure that the port you're running on is open, just in case.

AliasCodec USA Fri 13 Jan 2006 02:38 AM #2

Thank you very much for pointing me in that direction. It is indeed my codebase that is having an issue. SmaugFUSS worked perfectly, so now I am completely lost.

AliasCodec USA Fri 13 Jan 2006 03:04 AM #3

Somehow or another I got it to give me my greeting. As the program started up, I told my client to connect and as the program finished it's startup, I got the greeting on my client then got kicked. This is.. rather confusing for me, as I have never had any issues dealing with connection before and have not read about anyone having this issue.

Edit:

Thought it would be better to edit thank just postcount++ myself heh..

Ok, I went back and pulled an old copy of my MUD that worked in the past and was from before I did an overhaul over a year ago.. Anyways, that one wont connect either. So I am thinking that it may not be my code exactly, but the way that either my system or Cygwin is handling the way that connections are dealt with in my base. This is beyond me at the moment. I am thinking of scouring the internet for a pervious version of Cygwin if possible to see if that fixes it at all.

Zeno USA Fri 13 Jan 2006 03:17 AM #4

You got kicked? Did the MUD crash, or did it just disconnect you? Either way, you can use gdb to find out what's wrong.

AliasCodec USA Fri 13 Jan 2006 03:26 AM #5

Just got kicked. I am not all too familiar with using GDB except for when it gives me an error on crash and points me to where my errors are at. I apologize for seeming like a complete fool about this, but after not needing help for so long I am completely in the dark.

Zeno USA Fri 13 Jan 2006 03:30 AM #6

This is a great guide to gdb:
http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=3653

Basically, you should make a break in the function that handles connections and watch what happens.

Nick Gammon Australia Forum Administrator Fri 13 Jan 2006 03:55 AM #7

Quote:

I have disabled the firewall, all router firewalls ...

I hope you have re-enabled them. If you can't get it to work with localhost, that is obviously your first thing to fix.

If you get kicked, is there some sort of message? Maybe a breakpoint on the message would let you traceback to find the reason it is appearing. For example, your IP address is on a list that it rejects.

AliasCodec USA Fri 13 Jan 2006 04:02 AM #8

I put breaks in create_ident, nanny, and process_ident. Nothing came up. I may just be missing the function that deals with connections, as I cannot find where. I'm amazed as how little I know about the connection, never had to deal with it before. =\

AliasCodec USA Fri 13 Jan 2006 04:05 AM #9

Actually Nick, I was able to run Smaug with no issues at all. Able to connect, had a friend connect over the internet. It seems that my ROM base is having an issue. I get no message whatsoever. When using ZMud, it connects, then sits for about 5 seconds before disconnecting, with no message in Cygwin whatsoever recognizing that there was a connection. If I do not have the program running in Cygwin, ZMud will not connect at all.

Nick Gammon Australia Forum Administrator Fri 13 Jan 2006 05:11 AM #10

Assuming your version is similar to mine, this is where new connections are detected:


        if ( select( maxdesc+1, &in_set, &out_set, &exc_set, &null_time ) < 0 )
        {
            perror( "Game_loop: select: poll" );
            exit( 1 );
        }

        /*
         * New connection?
         */
        if ( FD_ISSET( control, &in_set ) )
            init_descriptor( control );

I put a break on the bold line, and that was where it stopped when I connected. You could see how far it gets after that.

AliasCodec USA Fri 13 Jan 2006 05:13 AM #11

Ok, I found an old version of my base that works. I compared the comm.c files and nothing is different that has to do with the connection of clients.

Something that I did notice earlier when I was able to get the greeting when I connected midstartup, the clients shows the "Sorry we are rebooting" message then it shows the greeting and options to enter the game. This is obviously something I have done, but I have no touched my base in so long it totally eludes me. I also cannot find my notebook full of the changes I have made, so that can't help. Is anyone familiar with ROM and what is called before "Exec failed; Closing child." line is printed? Because my mud does not even get to that line unless I.. hmm.

Actually, from the looks of it, the entire program is freezing. I cannot CTRL+C in Cygwin to close it as I once was able to. And it is freezing immediatly after it is fully up.

AliasCodec USA Fri 13 Jan 2006 05:21 AM #12

Came up with..

Quote:
Fri Jan 13 00:14:18 2006 :: Accursed Faction is ready to rock on port 4000.

Breakpoint 1, game_loop_unix (control=4) at comm.c:718
warning: Source file is more recent than executable.

718 d->outtop = 0;
(gdb)

When I put in that breakpoint..

Alright, I brought up task manager and watched it as it booted. It's doing a hotreboot but not reporting so in Cygwin, and then freezing when it completes. I see it start the new .exe and close the old one. It is actually rebooting over and over. Hrmm...

Samson USA Fri 13 Jan 2006 11:30 AM #13

Sounds like you have one of those "crashover" systems installed where the MUD will perform a copyover when it's about to crash instead. These kinds of strange "connection" problems are exactly why I always advise against using them.

Your MUD has a problem, that problem causes a segfault, your MUD intercepts the segfault signal and instead of letting it crash and dump a core, it does a copyover instead. You of course get no clue what might have happened and there is no core dump to try and debug.

So the first thing I'd look for now is someplace in the code that calls copyover after receiving the SIGSEGV signal. Disable that somehow and then try running the MUD again.

AliasCodec USA Sat 14 Jan 2006 03:57 AM #14

When I noticed the copyover routine repeating, that is the first thing I did. I took out all of the handlers for when it crashes to reboot and such. Now as soon as it gets running, it gives me the message in Cygwin saying that it exited normally. No errors in GDB, nothing.

Quote:
Fri Jan 13 22:57:52 2006 :: Accursed Faction is ready to rock on port 4000.

Program exited normally.
(gdb)

Nick Gammon Australia Forum Administrator Sat 14 Jan 2006 04:45 AM #15

Sounds like it hit an exit statement, and probably exit (0).

Doing a grep of the source indicates lots of exit statements, and some of them being exit (0).

(Exit (0) is a "normal termination").

Here is how I would find which one it is hitting ...

Use gdb, add a breakpoint on "exit" and then run it. I tested this by deliberately corrupting an area file, to see what would happen ...


(gdb) break exit
Breakpoint 1 at 0x8048bbc
(gdb) run
Starting program: /home/nick/rom/src/rom 
Breakpoint 1 at 0x42029cd6
Sat Jan 14 16:40:15 2006 :: [*****] FILE: haon.are LINE: 10
Sat Jan 14 16:40:15 2006 :: [*****] BUG: Fread_number: bad format.

Breakpoint 1, 0x42029cd6 in exit () from /lib/tls/libc.so.6
(gdb) bt
#0  0x42029cd6 in exit () from /lib/tls/libc.so.6
#1  0x0807499e in fread_number (fp=0x80d83a8) at db.c:2194
#2  0x08070bdc in load_area (fp=0x80d83a8) at db.c:406
#3  0x08070927 in boot_db () at db.c:348
#4  0x0806b7c1 in main (argc=2, argv=0xbffff974) at comm.c:417
#5  0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
(gdb)

In this example we can see that there was a problem in load_area, which is what we expect.

AliasCodec USA Sat 14 Jan 2006 04:51 AM #16

Ok, I went through my startup functions after the line ready to rock and put in breaks at increments of every 5th line until I found a point that it stopped.. 683 is the last line it loads, it never hits line 684.

Quote:

683 for ( d = descriptor_list; d; d = d->next )
684 {
685 maxdesc = UMAX( maxdesc, d->descriptor );
686 FD_SET( d->descriptor, &in_set );
687 FD_SET( d->descriptor, &out_set );
688 FD_SET( d->descriptor, &exc_set );
689
690 if ( d->ifd!=-1 && d->ipid!=-1 )
691 {
692 maxdesc = UMAX( maxdesc, d->ifd );
693 FD_SET( d->ifd, &in_set );
694 }
695 }

AliasCodec USA Sat 14 Jan 2006 05:04 AM #17

Went a step farther and commented that out just to see if it was stopping at every

Quote:
for ( d = descriptor_list; d; d = d->next )

Quote:

and found that it is indeed. This has me completely baffled, as everything thus far has. Thank you for being patient with me as I try and work through this.

Zeno USA Sat 14 Jan 2006 05:06 AM #18

What happens when you step? Doesn't seem like an infinite loop.

AliasCodec USA Sat 14 Jan 2006 05:11 AM #19

Ok, used step at the first break, line 683 where descriptor_list is first encountered, and kept going until I got a loop.

Quote:
(gdb) step
2500 for (hash = 0; hash < ARMY_HASH_SIZE; hash++){
(gdb) step
2501 for (pa = army_list[hash]; pa; pa = pa_next){
(gdb) step
2500 for (hash = 0; hash < ARMY_HASH_SIZE; hash++){
(gdb) step
2501 for (pa = army_list[hash]; pa; pa = pa_next){
(gdb) step
2500 for (hash = 0; hash < ARMY_HASH_SIZE; hash++){
(gdb) step
2501 for (pa = army_list[hash]; pa; pa = pa_next){
(gdb)

That continues over and over.

AliasCodec USA Sat 14 Jan 2006 05:23 AM #20

Commented the call to that funtion out, and now it's looping at another for statement.

Zeno USA Sat 14 Jan 2006 05:29 AM #21

Print ARMY_HASH_SIZE when you're in that function that has it. If it's quite large, just skip past that loop.

AliasCodec USA Sat 14 Jan 2006 05:41 AM #22

Guessing I used print correctly, never used it.

Quote:
2500 for (hash = 0; hash < ARMY_HASH_SIZE; hash++){
(gdb) step
2501 for (pa = army_list[hash]; pa; pa = pa_next){
(gdb) print ARMY_HASH_SIZE
No symbol "ARMY_HASH_SIZE" in current context.

Zeno USA Sat 14 Jan 2006 05:59 AM #23

You stepped too far. You need to use it under this line:

2500 for (hash = 0; hash < ARMY_HASH_SIZE; hash++){

Nick Gammon Australia Forum Administrator Sat 14 Jan 2006 06:00 AM #24

Now I'm a bit confused. You said before that you were getting a "normal termination" - that is, the program just exited.

Now you say you have found an infinite loop, in which case the program would not exit or do anything else.

Did you try putting a breakpoint on "exit" like I suggested?

You need to be aware that some loops may run for a long time, and seem to be taking forever in the debugger, but if they are iterating correctly they will eventually exit the loop. You can use something like "run to" to catch the exit from a loop.

Quote:

683 is the last line it loads, it never hits line 684.

What do you mean by that? Does it exit the program at that point?

Quote:

Commented the call to that funtion out, and now it's looping at another for statement.

I wouldn't start commenting out heaps of code, you will only introduce bugs doing that.

AliasCodec USA Sat 14 Jan 2006 06:11 AM #25

Nick-

At first it terminated, and I thought it was normal termination of the program. When not running in gdb it tells me the program was aborted, and in gdb, it says "Program exited normally.". I thought line 683 was the problem, but after using step, I got to the loop in armies.c lines 2500 and 2501. As to commenting out segments, I did that just to test and see if that piece was the only thing causing the crash. After three runs in gdb with the commented out bit, I recompiled with the segment back in, not commented out. I tried break exit, and nothing came up, the same termination of the program. It is exiting the program when it goes to the for lines involving ARMY_HASH_SIZE so far as I can tell.

Zeno-

I went back and did print at both lines, pasted the wrong bit of output in that post. Both times I got that same message.

Quote:
4545 army_combat_update();
(gdb) print ARMY_HASH_SIZE
No symbol "ARMY_HASH_SIZE" in current context.
(gdb) step
army_combat_update () at armies.c:2500
2500 for (hash = 0; hash < ARMY_HASH_SIZE; hash++){
(gdb) print ARMY_HASH_SIZE
No symbol "ARMY_HASH_SIZE" in current context.
(gdb) step
2501 for (pa = army_list[hash]; pa; pa = pa_next){
(gdb) print ARMY_HASH_SIZE
No symbol "ARMY_HASH_SIZE" in current context.

AliasCodec USA Sat 14 Jan 2006 07:48 AM #26

Alrighty, went back and started at the beginning.. spammed step to see how far I got before it crashed. I must have entered step a thousand times, but it got through ARMY_HAS_SIZE and the program terminated at the bolded line here:

Quote:
DESCRIPTOR_DATA* bring( ROOM_INDEX_DATA* room, char* arg ){
DESCRIPTOR_DATA *d;
int garbage;
char strsave[MIL];
FILE *fp;
CHAR_DATA* ch;

fclose( fpReserve );

if ( (ch = char_file_active( arg)) != NULL && ch->desc )
return ch->desc;

sprintf( strsave, "%s%s", PLAYER_DIR, capitalize( arg ) );
if ( ( fp = fopen( strsave, "r" ) ) == NULL ){
perror( strsave );
fpReserve = fopen( NULL_FILE, "r" );
return NULL;
}
fclose (fp);
fpReserve = fopen( NULL_FILE, "r" );

d = new_descriptor();
d->editor = 69;
garbage = load_char (d, arg);
load_obj (d->character);

d->character->next = char_list;
char_list = d->character;
d->character->next_player = player_list;
player_list = d->character;

reset_char(d->character);

char_to_room (d->character, room ? room : get_room_index(d->character->in_room->vnum));
d->character->logon = 0;

return d;
}

AliasCodec USA Sat 14 Jan 2006 07:56 AM #27

...And I should shoot myself now. The error is somewhere in the pfiles. I moved every pfile to another folder and started the mud, guessing that the error was in load_char, and sure enough, MUD started up fine, no problems.

Now to find out what is making the pfiles cause the error.