Complicated Error, are you able to help?

Posted by Trom on Wed 17 Nov 2004 01:30 PM — 5 posts, 20,392 views.

#0
I've never seen an error like this before, so please help.

This is what the gdb crash shows in cygwin:

Program received signal SIGSEGV, Segmentation fault.
0x610cdb11 in strlen () from /home/t13/area/cygwin1.dll
(gdb) bt
#0 0x610cdb11 in strlen () from /home/t13/cygwin1.dll
#1 0x610d18fc in wmemset () from /home/t13/cygwin1.dll
#2 0x610d5131 in wmemset () from /home/t13/cygwin1.dll
#3 0x610882af in cygwin1!aclcheck () from /home/t13/cygwin1.dll
#4 0x004495d5 in game_loop_unix (control=4) at comm.c:841
#5 0x00448ea6 in main (arg=1, arg=0xa0416a0) at comm.c:458


Code at comm.c:834 to comm.c:843
switch ( d->connected ) {
case CON_PLAYING:
if ( !run_olc_editor ( d ) )
substitute_alias ( d, d->incomm );
break;
default:
nanny ( d, d->incomm );
break;
}


Code at comm.c:458
game_loop_unix ( control );

Situation:
When a user starts creation, the moment after they re-enter they're new password the mud segmentation fault crashes. It doesn't matter whats typed, it happens. On a linux server i saw an error message (cygwin doesn't show it for some reason) that it gave the error that the port shouldn't be lower than 1024 (and the port is in the 8000's so that should not be a prob).

I've been working on this problem for a full day so far and still have no idea what the problem is. It gives no error information just segmentation fault, which i'm guessing means something is null. I recently removed the webserver from it which was included in rot codebase but it was like that for about 2 weeks now and gave no problems. If anyone has any ideas please say.
Amended on Wed 17 Nov 2004 01:34 PM by Trom
Australia Forum Administrator #1
Sounds like the stack is corrupted. The line at 841 is a call to nanny (which it would be in for processing passwords) but that isn't in the stack trace. Did you compile with the -G3 flag for debugging?

Since it always happens, I would use gdb (see my writeup on it) to put a breakpoint in nanny, then create a new character and see exactly what line causes the crash (by stepping through nanny).
#2
i'll have to do the read up on that finding the line, but yes i'm using -g3.

Trying for the first time this is what i came up with.

this is from comm.c, used break points and the 'next/list' method of finding the problem. It seems like (from the 2nd paragraph) line 762 causes the prob, just not sure why..

755 FD_ZERO ( &in_set );
756 FD_ZERO ( &out_set );
757 FD_ZERO ( &exc_set );
758 for ( d = descriptor_list; d; d = d->next )
759 {
760 maxdesc = UMAX ( maxdesc, d->descriptor );
761 FD_SET ( d->descriptor, &in_set );
762 FD_SET ( d->descriptor, &out_set );
763 FD_SET ( d->descriptor, &exc_set );
764 }



(gdb) next
761 FD_SET ( d->descriptor, &in_set );
(gdb) next
0x61088367 in cygwin1!aclcheck () from /home/t13/area/cygwin1.dll
(gdb) list
756 FD_ZERO ( &out_set );
757 FD_ZERO ( &exc_set );
758 for ( d = descriptor_list; d; d = d->next )
759 {
760 maxdesc = UMAX ( maxdesc, d->descriptor );
761 FD_SET ( d->descriptor, &in_set );
762 FD_SET ( d->descriptor, &out_set );



By the way, could you tell me a little about stack corruption, i'm unsure of what that is..
Amended on Fri 19 Nov 2004 12:47 PM by Trom
#3
Help please
USA #4
Programs keep track of which functions were called in which order by maintaining a call stack. Every time you call a function, it stores the return address so that when it finishes executing the fuction, it can go back to whomever called the function. Thus, to find a 'stack trace' you simply need to hop from call to call, retrieving the debugging information that was conveniently left there for you by the compiler (with the proper options enabled.)

All of this data is stored on the program stack. So, a stack corruption is when the data gets messed up somehow, e.g. writing beyond the bounds of an array. If you have:

int arr[5];
arr[5] = 5;

Then you will clobber something in memory, which might lead to a corrupted stack. There are lots of ways to corrupt the stack - the above is just one example and a fairly minor one at that.

This might not make that much sense to you though; it would make a lot more sense with a background in operating systems or even writing assembly code.


As to your problem, you might have bad values in your FD sets. Make sure that you don't - I know that's easier said than done. :-) Trace through the character creation code, since apparently that's where it happens.

Oh, and don't forget to make clean then make if you haven't done so already.