> Hey everyone,
>
> I'd appreciate any input and constructive criticism on the
> following. Hopefully it's something simple that I'm overlooking.
>
> I recently put together a simple check for a multiplaying character. It
> doesn't do anything except write to wiznet. It seems to be working fine,
> but today I noticed the mud I'm working on crashed in the
> function. Here's the GDB info:
>
> #0 0x8079fcc in check_multiplay (ch=0x40bd38e0) at comm.c:4388
> 4388 if ( (!IS_NPC(ch_check) && !IS_NPC(ch))
> (gdb) bt
> #0 0x8079fcc in check_multiplay (ch=0x40bd38e0) at comm.c:4388
> #1 0x80777f3 in nanny (d=0x40a3334c, argument=0x40a33774 "") at
> comm.c:3064
> #2 0x80740f0 in game_loop_unix (control=4) at comm.c:1183
> #3 0x80734fb in main (argc=4, argv=0xbffffdd4) at comm.c:497
> #4 0x4005ecbe in __libc_start_main () from /lib/libc.so.6
>
> #0 0x8079fcc in check_multiplay (ch=0x40bd38e0) at comm.c:4388
> 4388 if ( (!IS_NPC(ch_check) && !IS_NPC(ch))
> (gdb) info local
> ch = (CHAR_DATA *) 0x40bd38e0
> ch_check = (CHAR_DATA *) 0x40ba01d4
>
One slight oddity about gdb (at least the cygwin version) is that if a
multi-line if statement causes a SIGSEGV, then gdb reports the *first* line
of the if statement, even tho the Signal could have been generated on
another line in the if statement...
I'd check out the data inside ch and ch_check, notably their ->desc
members and the desc->host2 of each. My guess is one or both has a NULL
desc.
Tony
