01 Mar, 2010, Banner wrote in the 1st comment:
Votes: 0
Cross post: Blank Screen

To summarize:

I noticed when I'd connect to my MUD(Modified SWR1.0FUSS), I was not getting a greeting or any output, even after typing things in. I'd log in anyway and notice in another window that I was logged in, but still would receive no input in Window 1. I checked send_to_desc_color() and added a bug() for a null d->descriptor, and found out that d->descriptor was being set to 0 by accept() in comm.cpp.

A few things to note are:
1) Wikipedia says that a value of 0 is input, 1 is output, and 2 is error. I noticed that on booting a fresh copy of my MUD, I usually get a descriptor of 4+, but it usually starts assigning at 8.
2) At some point, it decides it wants to assign a descriptor of 0. Since I removed the call in send_to_desc_color() to return on a 0 descriptor, they can connect and play the MUD successfully, however, at some point, that person will be randomly disconnected later. I'm assuming this is because 0 should not be assigned.
3) This article claims that any value above -1 should be accepted, however, why am I receiving a 0 at some instances and >=4 everywhere else?

I have no knowledge of low level socket libraries and I know some of you are quite familiar with them, specifically accept(), so any information into fixing this issue, whether it is an issue at all, would be appreciated.
01 Mar, 2010, David Haley wrote in the 2nd comment:
Votes: 0
'accept' is probably not supposed to be returning 0 – there should be plenty of descriptors for it to be returning before it would even need to look at zero. You might want to look into what is happening when it starts assigning zero. Does it assign zero to just one person and then move on? How many people connect before it starts assigning zero? What happens when the person is disconnected when they have zero?
01 Mar, 2010, Banner wrote in the 3rd comment:
Votes: 0
David Haley said:
'accept' is probably not supposed to be returning 0 – there should be plenty of descriptors for it to be returning before it would even need to look at zero. You might want to look into what is happening when it starts assigning zero. Does it assign zero to just one person and then move on?
I can't find any one action that makes it start assigning a 0, but when it does assign a 0 to someone, the next people that logon always get a proper descriptor (1 more than the highest descriptor connected), until the 0 descriptor player disconnects, it is then assigned to the next person to connect who keeps it until they quit/get disconnected. I know that hotbooting the MUD after the error has occurred has no affect on fixing the error, it must be completely shutdown and restarted.


David Haley said:
How many people connect before it starts assigning zero?
I can't predict when it happens, but I'm trying to reproduce the error to find out more about when it starts assigning.

David Haley said:
What happens when the person is disconnected when they have zero?
The person with the 0 is disconnected, but it does not affect the MUD or anyone else. When they connect, they are fine up until the next disconnect. It has no other adverse affects beyond randomly disconnecting that player (as far as I know currently).
02 Mar, 2010, Banner wrote in the 4th comment:
Votes: 0
Player Bob quit.
Log: [*****] BUG: close_socket closing desc 0 on 1023
Comm: Bob has quit.


I followed the paper trail through do_quit, to extract_char, to close_socket, and line 1023 turns out to be:

SWGI:
}
compressEnd( dclose );

if( dclose->descriptor == maxdesc )
–maxdesc;
if( dclose->auth_fd != -1 )
close( dclose->auth_fd ); //1023

free_desc( dclose );
–num_descriptors;
return;
}

SMAUGFUSS:

}

compressEnd( dclose );

if( dclose->descriptor == maxdesc )
–maxdesc;

free_desc( dclose );
–num_descriptors;
return;
}


I noticed that that junk doesn't exist in Smaugfuss, so I'm assuming it's outdated unnecessary code I have that is being set at 0 and then being close errornously. Removing it will be okay, yes?

On further inspection, I noticed it is initalized as -1. After hotboot, I don't believe it'd be set, and end up as 0. Then when they quit, the check would tell it to go ahead and close it. Amiright?

Verified that was what was happening, and removing auth_fd and auth_inc harmed nothing and fixed everything. Thanks for the help. I hate old code.
0.0/4