Recently, I noticed that sometimes when I or other players would log into the MUD, the greeting and all subsequent data would fail to be sent, yet the connection was established. Sometimes using a separate client helps, and sometimes the issue resolves itself after several minutes and/or restarting the client/opening a new window. In the screenshot below, I connected and logged into the MUD and this is all I can see, and the player is connected to the MUD, just not receiving and output. My only guess is that perhaps something on the descriptor got eaten so it can't send more data or something, but alas, I wouldn't know where to begin, so help is requested and appreciated. If it helps, the text that DID get sent is in the mudtitle.ans file.

I've found that send_to_desc exting because d->descriptor is null. Which doesn't make sense because it sets sometimes but not others?

/* Writes to a descriptor, usually best used when there's no character to send to ( like logins ) */
void send_to_desc_color( const char *txt, DESCRIPTOR_DATA * d )              
{
   if( !d )
   {
      bug( "%s: NULL *d", __FUNCTION__ );
      return;
   }

   if( !txt )
   {
      bug( "%s: NULL txt", __FUNCTION__ );
      return;
   }
/*   if( !d->descriptor )
   {
      bug( "%s: NULL d->descriptor", __FUNCTION__ );                  
      return;
   }
*/
   write_to_buffer( d, colorize( txt, d ), 0 );
}

When someone connects and are assigned a descriptor of 0, this function won't send them anything because of the ifcheck !d->descriptor. I commented it out and connected, was assigned a descriptor of 0 and logged into the MUD without crashing anything, then connected in another window and was assigned a descriptor of 6, and myself and another player already had descriptors of 4 and 5. Is being assigned a descriptor of 0 not okay and is this check inside send_to_desc_color unncessary if a descriptor of 0 is okay? Check is inside stock FUSS bases.

And on an unrelated note, after having installed mccp:

make -s swgi -j5
o/comm.o: In function `write_to_descriptor(descriptor_data*, char const*, int)':
/home2/dev/swgi/src/comm.cpp:1413: undefined reference to `deflate'
o/mccp.o: In function `compressStart(descriptor_data*)':
/home2/dev/swgi/src/mccp.cpp:124: undefined reference to `deflateInit_'
o/mccp.o: In function `compressEnd(descriptor_data*)':
/home2/dev/swgi/src/mccp.cpp:149: undefined reference to `deflate'
/home2/dev/swgi/src/mccp.cpp:155: undefined reference to `deflateEnd'
collect2: ld returned 1 exit status
make[1]: *** [swgi] Error 1
make: *** [all] Error 2
dev@swgi:~/swgi/src$ 

zlib.h is included in the mccp.h file which is included in comm.cppo and mccpcpp. Smaug 1.9F compiles correctly with MCCP installed so I assume I missed a declaration of some sort somewhere. Any ideas?

Make sure that zlib is linked into the executable by supplying -lz to the linker in the Makefile. It should be in the L_FLAGS variable. I believe it's already there in stock SWRFUSS, but check it anyway.

It's also possible that the zlib header doesn't contain a wrapper for C++ linking. Try changing this:

#include 

To this:

#ifdef __cplusplus
extern "C" {
#endif
#include 
#ifdef __cplusplus
}
#endif

As for descriptor zero, I believe that belongs to standard input, and descriptor one belongs to standard output, so a socket should not have descriptor zero.

Caius said:

As for descriptor zero, I believe that belongs to standard input, and descriptor one belongs to standard output, so a socket should not have descriptor zero.

And if a descriptor of 0 is being assigned by the accept ifcheck, what would be the cause and fix? I have a descriptor of 0 at the moment and I haven't noticed anything out of the ordinary (aside from a random disconnect when another player logged off), but I also noticed that no other descriptors are assigned below 4.

Caius said:

Make sure that zlib is linked into the executable by supplying -lz to the linker in the Makefile. It should be in the L_FLAGS variable. I believe it's already there in stock SWRFUSS, but check it anyway.

It's also possible that the zlib header doesn't contain a wrapper for C++ linking. Try changing this:

#include 

To this:

#ifdef __cplusplus
extern "C" {
#endif
#include 
#ifdef __cplusplus
}
#endif

Fixed that issue. Thanks once again.

Banner said:

And if a descriptor of 0 is being assigned by the accept ifcheck, what would be the cause and fix?

I've never encountered this. However I found a thread where someone had the same behaviour. The fix is in the last post of page 1. Whether this is the same issue as yours, I can't say.

Caius said:

Banner said:

And if a descriptor of 0 is being assigned by the accept ifcheck, what would be the cause and fix?

I've never encountered this. However I found a thread where someone had the same behaviour. The fix is in the last post of page 1. Whether this is the same issue as yours, I can't say.

Not my issue.

   if( ( desc = accept( new_desc, ( struct sockaddr * )&sock, &size ) ) < 0 )
   {              
      perror( "New_descriptor: accept" );
      bug( "new_descriptor: accept" );
      set_alarm( 0 );
      return;      
   }  

I've seen this problem - but only sporadically. How often is this happening to you Banner?

Keirath said:

I've seen this problem - but only sporadically. How often is this happening to you Banner?

I can't say with any certainty because I only recently noticed it. After logging when send_to_desc_color() was finding a descriptor of 0, it seems to be happening nearly with every connection by 10-15 different connections, but I can only occasionally get the error myself.

EDIT: It also seems to only want to assign a 0 to the first person that connects. Anyone connecting after that receivers a normal descriptor that is 1 greater than the previos as long as that person with the 0 descriptor stays (this was after removing the check in send_to_desc_color() so a descriptor of 0 didn't stop the function from executing, thus allowing a 0 descriptor to login).

Well, after a bit of googling it seems that accept returns zero if stdin is closed. Grep for stdin. Also grep for things like "close( 0 )", and similar.

And keep in mind that you could be closing it implicitly as well:

descriptor = 0;
close( descriptor ); /* Oops */

And if these two lines happens in different functions it's harder to spot.

Caius said:

Well, after a bit of googling it seems that accept returns zero if stdin is closed. Grep for stdin. Also grep for things like "close( 0 )", and similar.

'stdin' is here:

db.cpp, bug()
      if( fpArea == stdin )
      {            
         iLine = 0;  
      }            
      else      
      {   

As flor 'close( 0 )', I've got several calls to close a variable, i.e. close(control) or close(fd), but not specific close(0).

Banner said:

   if( ( desc = accept( new_desc, ( struct sockaddr * )&sock, &size ) ) < 0 )
   {              
      perror( "New_descriptor: accept" );
      bug( "new_descriptor: accept" );
      set_alarm( 0 );
      return;      
   }  

If you want to stop assigning 0, change it to:

   if( ( desc = accept( new_desc, ( struct sockaddr * )&sock, &size ) ) <= 0 )
   {              
      perror( "New_descriptor: accept" );
      bug( "new_descriptor: accept" );
      set_alarm( 0 );
      return;      
   }  

If you do that then whoever was trying to connect would be disconnected, right?

Don't brush it under the rug. Somewhere, somehow, your stdin is closed. Get to the root of the problem and fix it permanently.

It might be helpful to have free_desc() alert you when descriptor 0 is being closed:

void free_desc( DESCRIPTOR_DATA * d )
{
   compressEnd( d );
   if( d->descriptor > 0 )
      close( d->descriptor );
   else if( d->descriptor == 0 )
      bug( "%s: }RALERT! Closing socket 0! BAD BAD BAD!", __FUNCTION__ );
   STRFREE( d->host );
   DISPOSE( d->outbuf );
   if( d->pagebuf )
      DISPOSE( d->pagebuf );
   DISPOSE( d->mccp );
   DISPOSE( d );
   --num_descriptors;
   return;
}

It may not be perfect, but you can always set a breakpoint in GDB and wait for this to happen and do a backtrace when it does.

Kayle said:



If you want to stop assigning 0, change it to:

code

I thought of that, but the problem is that whoever is connecting is always going to get that 0 descriptor when it's not taken ingame, so nobody will be able to connect once the error occurs.

Samson said:

It might be helpful to have free_desc() alert you when descriptor 0 is being closed:

void free_desc( DESCRIPTOR_DATA * d )
{
   compressEnd( d );
   if( d->descriptor > 0 )
      close( d->descriptor );
   else if( d->descriptor == 0 )
      bug( "%s: }RALERT! Closing socket 0! BAD BAD BAD!", __FUNCTION__ );
   STRFREE( d->host );
   DISPOSE( d->outbuf );
   if( d->pagebuf )
      DISPOSE( d->pagebuf );
   DISPOSE( d->mccp );
   DISPOSE( d );
   --num_descriptors;
   return;
}

It may not be perfect, but you can always set a breakpoint in GDB and wait for this to happen and do a backtrace when it does.

Man, I was hoping to avoid this at all costs.

Unfortunately it looks like you don't have much choice. It sounds to me like you have a spot somewhere that did something like desc = x instead of desc == x because what you describe shouldn't be happening.

Samson said:

Unfortunately it looks like you don't have much choice. It sounds to me like you have a spot somewhere that did something like desc = x instead of desc == x because what you describe shouldn't be happening.

What steps do you suggest I take? How do you connect to a running process with gdb, where should I place breakpoints, and what should I be looking for?