clean_obj_queue crash

Posted by Zeno on Sun 01 Aug 2004 10:45 PM — 10 posts, 37,717 views.

Zeno USA Sun 01 Aug 2004 10:45 PM #0


#0  0x42074d91 in calloc () from /lib/i686/libc.so.6
#1  0x42075bcc in free () from /lib/i686/libc.so.6
#2  0x080d05c0 in clean_obj_queue () at handler.c:3571
#3  0x0812ede2 in update_handler () at update.c:2099
#4  0x080a966a in game_loop () at comm.c:690
#5  0x080a8f61 in main (argc=8, argv=0xbffff7e0) at comm.c:304
#6  0x42015967 in __libc_start_main () from /lib/i686/libc.so.6

I haven't changed anything to do with those functions. I don't know why it crashed. null obj, perhaps?


void clean_obj_queue()
{
    OBJ_DATA *obj;

    while ( extracted_obj_queue )
    {
        obj = extracted_obj_queue;
        extracted_obj_queue = extracted_obj_queue->next;
    STRFREE( obj->name        );
    STRFREE( obj->description );
    STRFREE( obj->short_descr );
    STRFREE( obj->action_desc );
    DISPOSE( obj );
        --cur_qobjs;
    }
}

Nick Gammon Australia Forum Administrator Sun 01 Aug 2004 11:49 PM #1

It can't very well be null, the if test if for it to be not null. Corrupted maybe? If it keeps happening put a breakpoint on it and see what is in obj.

Zeno USA Mon 02 Aug 2004 12:29 AM #2

Corrupted was my second thought, and so far, its happened twice. Only problem is, no idea when it will happen.

Samson USA Mon 02 Aug 2004 03:30 AM #3

In your backtrace, why is frame 1 calling free() and frame 0 calling calloc() again right after? That doesn't seem right to me. I would suggest you take a look at your DISPOSE macro and make sure nothing fishy is happening there.

Zeno USA Mon 02 Aug 2004 03:53 AM #4


#define DISPOSE(point)                                                          \
do                                                                                      \
{                                                                                       \
  if (!(point))                                                                 \
  {                                                                                     \
        bug( "Freeing null pointer %s:%d", __FILE__, __LINE__ );        \
        fprintf( stderr, "DISPOSEing NULL in %s, line %d\n", __FILE__, __LINE__ ); \
  }                                                                                     \
  else                                                                          \
  {                                                                                     \
     free((point));                                                             \
     (point) = NULL;                                                            \
  }                                                                                     \
} while(0)

Doesn't look wrong to me.

Zeno USA Sun 08 Aug 2004 09:35 PM #5

Actually it happened again, but I was away on vacation when it happened, so this is only from the core.


#0  0x420751d1 in calloc () from /lib/i686/libc.so.6
#1  0x42074827 in calloc () from /lib/i686/libc.so.6
#2  0x42074544 in calloc () from /lib/i686/libc.so.6
#3  0x080a8c8f in write_to_pager (d=0x83784b8, txt=0x816cb84 "\e[0;32m", length=7)
    at color.c:1134
#4  0x080a8bfe in set_pager_color (AType=82, ch=0x839ab98) at color.c:1112
#5  0x08062034 in do_help (ch=0x839ab98, argument=0xbfffdd45 "RULES") at act_info.c:1951
#6  0x080d486c in interpret (ch=0x839ab98, argument=0xbfffdd45 "RULES") at interp.c:557
#7  0x080a9d03 in game_loop () at comm.c:671
#8  0x080a9631 in main (argc=8, argv=0xbfffe160) at comm.c:304
#9  0x42015967 in __libc_start_main () from /lib/i686/libc.so.6

Someone did help rules, but write_to_pager had problems, it seems.

Zeno USA Fri 20 Apr 2007 01:54 PM #6

Erk, I was thinking it someone fixed itself. Haven't seen it for at least a year. Suddenly it crashes again.

#0  0x000000316c4301b5 in raise () from /lib64/libc.so.6
#1  0x000000316c431b20 in abort () from /lib64/libc.so.6
#2  0x000000316c46766b in __libc_message () from /lib64/libc.so.6
#3  0x000000316c46ea30 in _int_free () from /lib64/libc.so.6
#4  0x000000316c47214c in free () from /lib64/libc.so.6
#5  0x000000000049be4c in clean_obj_queue () at handler.c:3905
#6  0x0000000000517de5 in update_handler () at update.c:2858
#7  0x0000000000478d31 in game_loop () at comm.c:1276
#8  0x000000000047a7d2 in main (argc=<value optimized out>, argv=<value optimized out>) at comm.c:606

Gohan_TheDragonball USA Sat 21 Apr 2007 12:31 AM #7


void clean_obj_queue()
{
    OBJ_DATA *obj;

    while ( extracted_obj_queue )
    {
        obj = extracted_obj_queue;
        extracted_obj_queue = extracted_obj_queue->next;
        if ( obj->name )
            STRFREE( obj->name        );
        if ( obj->description )
            STRFREE( obj->description );
        if ( obj->short_descr)
            STRFREE( obj->short_descr );
        if ( obj->action_desc )
            STRFREE( obj->action_desc );
        DISPOSE( obj );
            --cur_qobjs;
    }
}

thats what mine looks like

Gatewaysysop2 USA Sat 28 Apr 2007 03:44 PM #8

Have you guys not put in this fix? I dug into my old code (been patching all the fixes in since FUSS 1.4) and found that I'm consistent with the fix in this posting:

http://www.fussproject.org/index.php?a=topic&t=762

I have yet to even once encounter this crash either, although given the time it takes to surface, that may be a fluke too.

Just tossing that out in case it helps anyone. It appears that this is the way the code is in FUSS as of 1.7 as well.

Hope that helps!

Samson USA Wed 02 May 2007 02:19 PM #9

Wow, talk about resurrecting the past :P

Anyway, yes. That's exactly the kind of mysterious crash that fix was intended to prevent. You most likely ran into one of the dangling pointers. Crashing doesn't happen that often with this particular problem, but when it does the headscratching is usually the common reaction :)