Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
 Couple bugs
Today, 5:42 pm
By Remcon
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
Bug in will_fall( )
Oct 23, 2017, 1:35 am
By GatewaySysop
Bug in do_zap( ), do_brandish( )
Oct 18, 2017, 1:52 pm
By GatewaySysop
Bug in get_exp_worth( )
Oct 10, 2017, 1:26 am
By GatewaySysop
LOP 1.45
Author: Remcon
Submitted by: Remcon
LOP Heroes Edition
Author: Vladaar
Submitted by: Vladaar
Heroes sound extras
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.3
Author: Vladaar
Submitted by: Vladaar
Memwatch
Author: Johan Lindh
Submitted by: Vladaar
Users Online
CommonCrawl, Yandex, DotBot, Google, Yahoo!

Members: 0
Guests: 8
Stats
Files
Topics
Posts
Members
Newest Member
477
3,705
19,232
608
LAntorcha
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » Codebases » AFKMud Support & Development » do_disconnect
Forum Rules | Mark all | Recent Posts

do_disconnect
< Newer Topic :: Older Topic >

Pages:<< prev 1 next >>
Post is unread #1 May 10, 2011, 9:37 pm   Last edited May 10, 2011, 9:39 pm by crone
Go to the top of the page
Go to the bottom of the page

crone
Fledgling
GroupMembers
Posts15
JoinedMay 10, 2011

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
       
Post is unread #2 May 11, 2011, 2:25 pm
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,858
JoinedJul 26, 2005

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.
       
Post is unread #3 May 11, 2011, 6:08 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

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 :P
       
Post is unread #4 May 11, 2011, 7:26 pm
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,858
JoinedJul 26, 2005

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.
       
Post is unread #5 May 11, 2011, 7:42 pm
Go to the top of the page
Go to the bottom of the page

crone
Fledgling
GroupMembers
Posts15
JoinedMay 10, 2011

Samson said:

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

<br />
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 :P


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

       
Post is unread #6 May 12, 2011, 1:27 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

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 :P
       
Post is unread #7 May 12, 2011, 2:42 am
Go to the top of the page
Go to the bottom of the page

crone
Fledgling
GroupMembers
Posts15
JoinedMay 10, 2011

lol, no no
i dont want to disconnect anyone :D
so i like a clear and debugged code :)
:innocent:
       
Post is unread #8 May 12, 2011, 4:00 am
Go to the top of the page
Go to the bottom of the page

Keirath
Magician
GroupMembers
Posts144
JoinedJan 24, 2008

How do you recommend fixing it, out of curiosity?
       
Post is unread #9 May 12, 2011, 11:33 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

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.
       
Post is unread #10 May 12, 2011, 3:20 pm
Go to the top of the page
Go to the bottom of the page

Keirath
Magician
GroupMembers
Posts144
JoinedJan 24, 2008

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?
       
Post is unread #11 May 12, 2011, 4:32 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

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.
       
Post is unread #12 May 12, 2011, 4:47 pm
Go to the top of the page
Go to the bottom of the page

Keirath
Magician
GroupMembers
Posts144
JoinedJan 24, 2008

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.
       
Post is unread #13 May 12, 2011, 7:42 pm
Go to the top of the page
Go to the bottom of the page

crone
Fledgling
GroupMembers
Posts15
JoinedMay 10, 2011

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

ty for your patience
       
Post is unread #14 May 17, 2011, 8:16 am
Go to the top of the page
Go to the bottom of the page

crone
Fledgling
GroupMembers
Posts15
JoinedMay 10, 2011

ty for help

finally the do_disconnect works without crashing :D

       
Post is unread #15 May 17, 2011, 8:33 am   Last edited May 17, 2011, 8:35 am by crone
Go to the top of the page
Go to the bottom of the page

crone
Fledgling
GroupMembers
Posts15
JoinedMay 10, 2011

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

       
Pages:<< prev 1 next >>