gdb debug with set_char_color?

Posted by Zeno on Sun 02 May 2004 04:53 AM — 13 posts, 34,209 views.

Zeno USA Sun 02 May 2004 04:53 AM #0

Alright, so the MUD crashes of course, and it does a coredump. Here's what the coredump gives:


#0  0x080a877e in set_char_color (AType=7, ch=0x836bf80) at color.c:970
970        ch->desc->pagecolor = ch->colors[AType];
(gdb) bt
#0  0x080a877e in set_char_color (AType=7, ch=0x836bf80) at color.c:970
#1  0x080ad3d1 in act (AType=37, format=0x816fce0 "You hear something's death cry.",
    ch=0x852b358, arg1=0x0, arg2=0x0, type=0) at comm.c:2821
#2  0x080c7811 in death_cry (ch=0x852b358) at fight.c:3301
#3  0x080f2fd3 in mprog_death_trigger (killer=0x0, mob=0x852b358) at mud_prog.c:2630
#4  0x080c78a7 in raw_kill (ch=0x836a000, victim=0x852b358) at fight.c:3337
#5  0x080c6314 in damage (ch=0x836a000, victim=0x852b358, dam=108, dt=230) at fight.c:2425
#6  0x080de7b3 in spell_area_attack (sn=230, level=103, ch=0x836a000, vo=0x0) at magic.c:5517
#7  0x080df8ec in spell_smaug (sn=230, level=103, ch=0x836a000, vo=0x0) at magic.c:6137
#8  0x0810f927 in check_skill (ch=0x836a000, command=0xbfffe380 "shriek",
    argument=0xbfffe7d6 "") at skills.c:404
#9  0x080d36e1 in interpret (ch=0x836a000, argument=0xbfffe7d6 "") at interp.c:468
#10 0x080a95bb in game_loop () at comm.c:670
#11 0x080a8ee9 in main (argc=8, argv=0xbfffebf0) at comm.c:303
#12 0x42015967 in __libc_start_main () from /lib/i686/libc.so.6

So someone used shriek, and it killed something. But what caused the crash? set_char_color? I don't see why that would, I haven't changed it.

David Haley USA Sun 02 May 2004 05:28 AM #1

I'd say that the problem likes comes from ch->desc being corrupted.

From gdb try:

print ch
print ch->name
print ch->desc
print ch->desc->port (or some other member of desc)

And see if any of those gives you an error; that'll help track down the problem.

Zeno USA Sun 02 May 2004 05:34 AM #2

Yeah I did that, but I didn't go as far as desc->port.


(gdb) print ch
$1 = (struct char_data *) 0x836bf80
(gdb) print ch->name
$2 = 0x835b080 "Kumori"
(gdb) print ch->desc
$3 = (struct descriptor_data *) 0x0
(gdb) print ch->desc->port
Cannot access memory at address 0x18

That seems to be it? Never got anything like this. Well, I may have, but I don't think I ever fixed it.

David Haley USA Sun 02 May 2004 05:45 AM #3

Yes, this means that the "Kumori" character has no descriptor, but the function thought that it should have one. Maybe the player went link-dead, but that's unlikely. Is "Kumori" a player, a mob, or something else?

The easy solution is to add the following:

if ( !ch->desc )
  return;

At the top of the send_to_char function. It would be better however to find out why the character didn't have a descriptor in the first place, however.

Zeno USA Sun 02 May 2004 05:53 AM #4

It was an Immortal... But most of the Usernames are "Unknown". Everyone has had a descriptor. They weren't linkdead or anything. I have no idea why it thought they didn't have a descriptor. I'll look it over...

[EDIT] If I try to debug the core now, I get:


#0  0x080a877e in send_to_desc_color (txt=0x7 <Address 0x7 out of bounds>, d=0x836bf80)
    at color.c:992
992           bug( "%s", "send_to_desc_color: NULL *d" );
(gdb) bt
#0  0x080a877e in send_to_desc_color (txt=0x7 <Address 0x7 out of bounds>, d=0x836bf80)
    at color.c:992
#1  0x080ad3d1 in do_name (ch=0x836bf80, argument=0x0) at comm.c:2840
#2  0x080c7811 in raw_kill (ch=0x835a2a8, victim=0x835a120) at fight.c:3332
#3  0x080f2fd3 in mprog_give_trigger (mob=0x852b358, ch=0x852b358, obj=0xbfffda88)
    at mud_prog.c:2657
#4  0x080c78a7 in raw_kill (ch=0x80c191b, victim=0x836a000) at fight.c:3353
#5  0x080c6314 in damage (ch=0x836a000, victim=0x836a000, dam=108, dt=230) at fight.c:2443
#6  0x080de7b3 in spell_area_attack (sn=230, level=103, ch=0x836a000, vo=0x0) at magic.c:5453
#7  0x080df8ec in spell_smaug (sn=230, level=103, ch=0x836a000, vo=0x0) at magic.c:6148
#8  0x0810f927 in check_skill (ch=0x836a000, command=0xbfffe380 "shriek",
    argument=0xbfffe7d6 "") at skills.c:420
#9  0x080d36e1 in interpret (ch=0x836a000, argument=0xbfffe7d6 "") at interp.c:485
#10 0x080a95bb in game_loop () at comm.c:701
#11 0x080a8ee9 in init_socket (port=1108589772) at comm.c:353
#12 0x42015967 in ?? ()

I can't print any ch content, or anything. I guess its probably because the exec has changed.

[EDIT 2]
The function already had that ifcheck in it...


void set_char_color( sh_int AType, CHAR_DATA *ch )
{
   if ( !ch || !ch->desc )
      return;

   write_to_buffer( ch->desc, color_str( AType, ch ), 0 );
   ch->desc->pagecolor = ch->colors[AType];
}

Nick Gammon Australia Forum Administrator Sun 02 May 2004 09:09 PM #5

There was a similar problem in this post:

http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=4056

It sounded like it wasn't actually the set_char_color part, something had corrupted memory shortly before the crash.

Zeno USA Sun 02 May 2004 09:51 PM #6

Yeah, I looked that over. Its with cygwin though, so it may be a little different from what I'm looking at.

Nick Gammon Australia Forum Administrator Sun 02 May 2004 10:51 PM #7

I don't think Cygwin will make much difference. I am worried about this line in the bt:

#1 0x080ad3d1 in do_name (ch=0x836bf80, argument=0x0) at comm.c:2840

The NULL argument "argument" looks wrong, one of the first things do_name does is:

argument[0] = UPPER(argument[0]);

Zeno USA Sun 02 May 2004 11:24 PM #8

raw_kill doesn't call do_name in any way does it? I think I checked it over, and saw it called something to do with un-morphing a character. Does morph call do_name? I'll look over a few things now.

Samson USA Mon 03 May 2004 11:53 AM #9

There was a fix in the recent FUSS packages for this. These packages should be updated here and have been on MUD Planet for awhile now. Assuming this is the same problem anyway. there was a crash in the color processing itself if it was being used on a descriptor with no character, but you appear to have the opposite problem. A character with no descriptor.

One other thing to consider - was the immortal switched? I notice switching tends to have all sorts of lovely pitfalls associated with it and this might be one of them.

Try updating your color.c file with the one in the current FUSS package and see if that helps. If not then there's something that needs to be tracked down.

Zeno USA Mon 03 May 2004 08:18 PM #10

I'll look it over. Switch is a really poor command, I'm just gonna disable it. I don't think I changed color.c, so I can probably just update it without checking for changes.

David Haley USA Mon 03 May 2004 08:58 PM #11

Switch seems to me like a lot of other stuff in SMAUG - added as a "cool feature" but that wasn't ever fully debugged. Add to that the problem that the basic infrastructure doesn't seem to like the notion of switching, so 'switch' is a hack on top of the original system. It's also poorly documented to boot. :)

Zeno USA Sun 09 May 2004 08:22 PM #12

Once again, another crash.


#0  0x080a8762 in set_char_color (AType=7, ch=0x83682e0) at color.c:970
970        ch->desc->pagecolor = ch->colors[AType];
(gdb) bt
#0  0x080a8762 in set_char_color (AType=7, ch=0x83682e0) at color.c:970
#1  0x080ad3bd in act (AType=18, format=0x8165b2b "$n has lost $s link.", ch=0x836b070, arg1=0x0, arg2=0x0, type=5)
    at comm.c:2821
#2  0x080aa019 in close_socket (dclose=0x8364ec0, force=1 '\001') at comm.c:1045
#3  0x080aa70b in write_to_buffer (d=0x8364ec0, txt=0x81b16e0 "Demonicinu has lost his link.\n\r", length=57) at comm.c:1384
#4  0x080a8996 in send_to_char_color (txt=0x7 <Address 0x7 out of bounds>, ch=0x836b070) at color.c:1065
#5  0x080a8ad5 in send_to_char (txt=0x81b16e0 "Demonicinu has lost his link.\n\r", ch=0x836b070) at color.c:1119
#6  0x080ad3c9 in act (AType=18, format=0xbfff9067 "As the demon dies, it gives out a cry, calling another.", ch=0x8371c90,
    arg1=0x0, arg2=0x0, type=0) at comm.c:2822
#7  0x080ea7b2 in do_mpecho (ch=0x8371c90, argument=0xbfff9067 "As the demon dies, it gives out a cry, calling another.")
    at mud_comm.c:536
#8  0x080d3863 in interpret (ch=0x8371c90, argument=0xbfff9067 "As the demon dies, it gives out a cry, calling another.")
    at interp.c:547
#9  0x080f2383 in mprog_do_command (cmnd=0xbfff8c60 "\200\214ÿ¿°à2\bl\215ÿ¿p\215ÿ¿", mob=0x8371c90, actor=0x836b070,
    obj=0x0, vo=0x0, rndm=0x83682e0, ignore=0 '\0', ignore_ors=0 '\0') at mud_prog.c:2242
#10 0x080f1f35 in mprog_driver (
    com_list=0x8358970 "mpecho As the demon dies, it gives out a cry, calling another.\n\rmpmload 1004\n\r", mob=0x8371c90,
    actor=0x836b070, obj=0x0, vo=0x0, single_step=0 '\0') at mud_prog.c:1940
#11 0x080f2bae in mprog_percent_check (mob=0x8371c90, actor=0x836b070, obj=0x0, vo=0x0, type=4) at mud_prog.c:2454
#12 0x080f2faa in mprog_death_trigger (killer=0x0, mob=0x8371c90) at mud_prog.c:2627
#13 0x080c7893 in raw_kill (ch=0x836b070, victim=0x8371c90) at fight.c:3337
#14 0x080c6300 in damage (ch=0x836b070, victim=0x8371c90, dam=2, dt=1000) at fight.c:2425
#15 0x080c3f7f in one_hit (ch=0x836b070, victim=0x8371c90, dt=1000) at fight.c:1356
#16 0x080c2caf in multi_hit (ch=0x836b070, victim=0x8371c90, dt=-1) at fight.c:800
#17 0x080c8a66 in do_kill (ch=0x836b070, argument=0xbfffe092 "demon") at fight.c:3905
#18 0x080d3863 in interpret (ch=0x836b070, argument=0xbfffe092 "demon") at interp.c:547
#19 0x080a95a7 in game_loop () at comm.c:670
#20 0x080a8ed5 in main (argc=8, argv=0xbfffe4b0) at comm.c:303
#21 0x42015967 in __libc_start_main () from /lib/i686/libc.so.6



(gdb) print ch
$1 = (struct char_data *) 0x83682e0
(gdb) print ch->name
$2 = 0x835e198 "Demonicinu"
(gdb) print ch->port->desc
There is no member named port.
(gdb) print ch->desc
$3 = (struct descriptor_data *) 0x0
(gdb) print ch->desc->port
Cannot access memory at address 0x18

But I haven't updated color.c yet, heh. Hopefully that will fix it.