hello, i've got some problem with the function "do_disconnect" on AFKMud code 2.14, i use the original Samson code

Desc|     Constate      |Idle|    Player    | HostIP                   
----+-------------------+----+--------------+--------------------------
   4| Playing           |   0| Crone        | local-host 
   5| Playing           |   2| Prova        | local-host 
2 users.

[32700hp 32700m 32700mv]  (Invis 101) <#2850> disco 5
Log: Crone: disco 5
Log: Crone has disconnected Prova
Comm: Closing link to Prova.
Prova has lost his link.
Ok.
Alas, the hideous malevalent entity known only as 'Lag' rises once more!
Bugs: [*****] BUG: ALARM CLOCK! In section game_loop
Bugs: Obtained 11 stack frames.
Bugs: 0   afkmud                              0x000000010013f54d _Z3bugPKcz + 566
Bugs: 1   afkmud                              0x000000010012862f _ZL12caught_alarmi + 122
Bugs: 2   libSystem.B.dylib                   0x00007fff84f5266a _sigtramp + 26
Bugs: 3   ???                                 0x00007fff5fc12b24 0x0 + 140734799883044
Bugs: 4   libstdc++.6.dylib                   0x00007fff814d107e _ZNSs4_Rep8_M_cloneERKSaIcEm + 88
Bugs: 5   libstdc++.6.dylib                   0x00007fff814d1111 _ZNSs6assignERKSs + 59
Bugs: 6   afkmud                              0x0000000100126f41 _Z13process_inputv + 707
Bugs: 7   afkmud                              0x00000001001270d5 _Z9game_loopv + 126
Bugs: 8   afkmud                              0x0000000100127e8f main + 618
Bugs: 9   afkmud                              0x0000000100003428 start + 52
Bugs: 10  ???                                 0x0000000000000002 0x0 + 2
Log: Possible infinite loop detected during game operation. Restarting game_loop().

my OS is Mac OSX 10.6.7

any help will be appreciated

Yea there is a problem in there just not sure where.

If I get time I'll look at it later if no one beats me to it.

Does the game continue on properly when it tells you it found an infinite loop and is restarting game_loop?

Pretty sure this mess is the result of some stupidity on my part in removing things from lists that are still being iterated over. I doubt process_input is going to be happy if the person you just disconnected was supposed to be the next descriptor in the loop

Yea it will continue on, when running in gdb of course it gives the problem is in issue in process_input but that is after the overflow etc... I'm not that great at C++ lol so no clue on it.

sometimes it continue, sometimes the game crash
if i'm the last in the list and i try to disconnect someone it will work fine, if my descriptor id is < of the id i want to disconnect mud crash (if i'm lucky) or goes in loop

Yep, that all but confirms it then. It'll need to be fixed. It won't be something quick though so for now try not to disconnect too many people

lol, no no
i dont want to disconnect anyone :D
so i like a clear and debugged code

How do you recommend fixing it, out of curiosity?

Descriptors will need to be marked as disconnected if close_socket is called, rather than simply dropping them immediately. Then in between process_input and process_output a new cleanup loop will need to be made to actually disconnect them.

Using your idea, I came up with a system to do just that. Here it is.
I added a bool disconnected in close_socket and commented out the portion that removed it from the dlist and deleted the pointer.
Instead, I had close_socket set the disconnected bool to TRUE. Between process_input and process_output, I added this.

      std::list< descriptor_data* >::iterator i = dlist.begin();
      while (i != dlist.end())
      {
         if( (*i)->disconnected )
         {
             descriptor_data *s = *i++;
             dlist.remove( s );
             deleteptr( s );
         }
         else
           ++i;
      }

Is this an acceptable solution? Or does someone forsee issues I have overlooked?

That should do the trick actually. You may also want to be sure that descriptors marked as disconnected no longer read from their input buffers or write to their output buffers since they're supposed to be dropped at that point.

Well, I was rather proud of myself. Will definitely do that.

I also realized if you are removing from the list as you go through, a for statement won't work. So I tried the while statement and voila.

and what do I do exactly?
I need a step-by-step

ty for your patience

ty for help

finally the do_disconnect works without crashing :D

in descriptor.h
at very end of the class descriptor_data
old code

   bool can_compress;
   bool is_compressing;

new code

   bool can_compress;
   bool disconnected;      /* fix by Keirath for close_socket */
   bool is_compressing;

in descriptor.c
in void close_socket
old code

   dlist.remove( d ); 	
   if( d->descriptor == maxdesc )
      --maxdesc;
   --num_descriptors;
   deleteptr( d );

new code

/*
 * fix by Keirath
 */
/*   dlist.remove( d ); 	
   if( d->descriptor == maxdesc )
      --maxdesc;
   --num_descriptors;
   deleteptr( d ); */
	d->disconnected = true;

in comm.c
inside void game_loop
old code

      // If no descriptors are present, why bother processing input for them?
      if( dlist.size(  ) > 0 )
         process_input(  );

#if !defined(__CYGWIN__)
#ifdef MULTIPORT
      mud_recv_message(  );
#endif
#endif
#ifdef IMC
      imc_loop(  );
#endif

new code

     // If no descriptors are present, why bother processing input for them?
      if( dlist.size(  ) > 0 )
         process_input(  );

// fix by Keirath for close_socket
      std::list< descriptor_data* >::iterator i = dlist.begin();
      while (i != dlist.end())
      {
         if( (*i)->disconnected )
         {
             descriptor_data *s = *i++;
             dlist.remove( s );
             deleteptr( s );
         }
         else
           ++i;
      }

#if !defined(__CYGWIN__)
#ifdef MULTIPORT
      mud_recv_message(  );
#endif
#endif
#ifdef IMC
      imc_loop(  );
#endif