Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
auth_update crash
Dec 23, 2017, 10:15 pm
By Remcon
check_tumble
Dec 18, 2017, 7:21 pm
By Remcon
parse description bug
Dec 15, 2017, 10:08 pm
By Remcon
Couple bugs
Dec 12, 2017, 5:42 pm
By Remcon
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
LoP 1.46
Author: Remcon
Submitted by: Remcon
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
Users Online
CommonCrawl, Majestic-12, Yahoo!, Google

Members: 0
Guests: 20
Stats
Files
Topics
Posts
Members
Newest Member
478
3,708
19,242
612
Jacki72H
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » General » Coding » MCCP crash
Forum Rules | Mark all | Recent Posts

MCCP crash
< Newer Topic :: Older Topic >

Pages:<< prev 1 next >>
Post is unread #1 Aug 7, 2009, 9:51 pm
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,868
JoinedJul 26, 2005

Ok here's the crash information

Program received signal SIGPIPE, Broken pipe.
0x40000402 in __kernel_vsyscall ()
(gdb) bt
#0  0x40000402 in __kernel_vsyscall ()
#1  0x004fd461 in send () from /lib/libc.so.6
#2  0x08159484 in process_compressed (d=0x9906e98) at mccp.c:104
#3  0x0815979b in compressEnd (d=0x9906e98) at mccp.c:179
#4  0x080e1799 in close_socket (dclose=0x9906e98, force=0 '\0') at comm.c:1763
#5  0x080e0878 in game_loop () at comm.c:1290
#6  0x080e002d in main (argc=6, argv=0xbfcf95f0) at comm.c:816
(gdb) frame 1
#1  0x004fd461 in send () from /lib/libc.so.6
(gdb) frame 2
#2  0x08159484 in process_compressed (d=0x9906e98) at mccp.c:104
104              if ( ( nWrite = send( d->descriptor, d->mccp->out_compress_buf + iStart, nBlock, 0 ) ) < 0 )
Current language:  auto; currently c++
(gdb) print nWrite
$1 = -32
(gdb) print d->descriptor
$2 = 6
(gdb) print d->mccp->out_compress_buf
$3 = (unsigned char *) 0x99ed608 "\003"
(gdb) print iStart
$4 = 0
(gdb) print nBlock
$5 = -32

Now it was originally using write instead of send but it kept crashing so I tried switching it to send and yet still crashing. The only odd thing I've noticed is that in all the cases nWrite was -32 nBlock sometimes is -32 but have seen it with other numbers as well. The only time it crashes is if your connected and you go link dead completely. Quitting, normal sending etc... all work fine just something about going link dead and it getting to that line and down it goes. Although I haven't tried it I've been tempted to have Vladaar put a copy of LoP on his server and see if it crashes at the same point or just testing his out on my pc. LoP gives no crash on my pc when I go link dead lol. Figured I'd post here first though and see if anyone else knew right off how to deal with the problem. The crash I kept getting when it used the write function that came in the mccp.c file was something about __write_nocancel system function and then one after it (where it finally crashed).
       
Post is unread #2 Aug 10, 2009, 6:44 am
Go to the top of the page
Go to the bottom of the page

Darrik
Fledgling
GroupMembers
Posts20
JoinedJan 29, 2008


Add:

signal( SIGPIPE, SIG_IGN );

To the rest of your signal function calls ( they are in the game_loop in SWR, just grep for signal ).

This will ignore the SIGPIPE call, which is largely useless.

If your game still crashes after the signal call is added, at least you'll have useful GDB data.
       
Post is unread #3 Aug 10, 2009, 6:55 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Shouldn't the broken pipe be handled normally using return codes etc.? Why is a signal being sent?
       
Post is unread #4 Aug 10, 2009, 9:13 am
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,868
JoinedJul 26, 2005

Not sure why it is sending a signal, I use gMUDix and if I simply disconnected it was fine, it was if I fully closed it out. There were problems also though with ones using Zmud etc... going link dead and causing the same crash. I did work around it so that if they went link dead it wouldn't bother doing the process_compressed. But still think it is odd since never had this problem on anything before lol.

Hmm handling the signal is one way to go about it might give that a try sometime.
       
Post is unread #5 Aug 10, 2009, 9:23 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Personally I think it's fishy to be ignoring the signal... I was fairly certain that you could detect these things inline (using return values) instead of having to rely on trapping/ignoring a signal.
       
Post is unread #6 Aug 10, 2009, 9:31 am
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,868
JoinedJul 26, 2005

Well I'm open to suggestions on how to try handling it. I just had to stop it from crashing all the time (since lots of people seem to like going link dead every little bit lol).
       
Post is unread #7 Aug 10, 2009, 9:42 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Well I guess I'd start with looking at the return values of, e.g., send, to see what a -32 return value means... also, it would be worth looking into why nBlock is -32.
       
Post is unread #8 Aug 10, 2009, 11:52 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

What exactly is that SIGPIPE stuff even supposed to be for? I never really got why that was there and never bothered to go looking into it :)
       
Post is unread #9 Aug 10, 2009, 12:16 pm
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,868
JoinedJul 26, 2005

bool process_compressed( DESCRIPTOR_DATA *d )
{
   int iStart = 0, nBlock, nWrite, len;

   if( !d->mccp->out_compress )
      return true;

   /* Try to write out some data.. */
   len = d->mccp->out_compress->next_out - d->mccp->out_compress_buf;

   if( len > 0 )
   {
      /* we have some data to write */
      for( iStart = 0; iStart < len; iStart += nWrite )
      {
         nBlock = UMIN( len - iStart, 4096 );
         if( ( nWrite = write( d->descriptor, d->mccp->out_compress_buf + iStart, nBlock ) ) < 0 )
         {
            if( errno == EAGAIN || errno == ENOSR )
               break;

            return false;
         }

         if( !nWrite )
            break;
      }

      if( iStart )
      {
         /* We wrote "iStart" bytes */
         if( iStart < len )
            memmove( d->mccp->out_compress_buf, d->mccp->out_compress_buf + iStart, len - iStart );

         d->mccp->out_compress->next_out = d->mccp->out_compress_buf + len - iStart;
      }
   }
   return true;
}

This is the normal way it looked before I changed it to send instead of write. The over all deal is the same as the send version just different routes but all giving the same signal and all. No clue on what exactly SIGPIPE is and all but its annoying lol.
I'm not really sure why nblock gets to -32 ive seen it be like 6 etc... though and still give the same crash lol. Yea I'll have to check later and see what -32 means when it comes from write and send later.
       
Post is unread #10 Aug 10, 2009, 12:43 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Did some digging deep into the errno.h system header and eventually found that -32 equates to code 32 - the EPIPE error. Or, as you've seen, a broken pipe. All the Google hits on this seem to indicate it means the client you're trying to send the information to has been disconnected. Any further attempts to shove data in its direction will fail. So the function is doing right by bailing out when EPIPE is encountered and you don't want to be ignoring that condition elsewhere or you'll just end up with more spam from socket errors, or I guess in your case it just crashes.
       
Post is unread #11 Aug 10, 2009, 1:30 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

I would wager that the signal is being sent because the code is in fact not doing the right thing and is trying to write to a socket after the pipe has been detected as being closed or something similar.

Lots of codebases handle people going linkdead without receiving this signal, so I would suggest that there is in fact a bug in this code somewhere and not some general need to handle broken pipe signals.
       
Post is unread #12 Aug 10, 2009, 2:08 pm
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,868
JoinedJul 26, 2005

That is possible lol. Well thats good though then the way i went about doing it is fine and dandy. All it does is not do the process_compressed if the connection has went link dead. I'm not ignoring the case just not doing this part and then no crashes or any issues since it handles fine after it and all.

Well thanks for all the help on it anyways :)
       
Post is unread #13 Aug 11, 2009, 11:21 am
Go to the top of the page
Go to the bottom of the page

Darrik
Fledgling
GroupMembers
Posts20
JoinedJan 29, 2008


Sorry, been busy. The issue is that (after the write function is called ) one has no opportunity to handle the error until it's returned... ignoring the SIGPIPE signal gives you one opportunity to handle the error properly. The if statement inside which write is called checks for a return value.
       
Pages:<< prev 1 next >>