_int_free crash

Posted by Zeno on Sun 12 Dec 2004 06:27 PM — 6 posts, 23,476 views.

USA #0
#0  0x00499423 in _int_free () from /lib/tls/libc.so.6
#1  0x0049a72b in free () from /lib/tls/libc.so.6
#2  0x080cbc4b in clean_obj_queue () at handler.c:3594
#3  0x08133bd9 in update_handler () at update.c:2222
#4  0x080a5342 in game_loop () at comm.c:698
#5  0x080a4bb6 in main (argc=8, argv=0xfef5fe50) at comm.c:308


Not sure why a crash like this happened. Recently did a clean compile.

(gdb) f 2
#2  0x080cbc4b in clean_obj_queue () at handler.c:3594
3594        DISPOSE( obj );
(gdb) p obj
$1 = (OBJ_DATA *) 0x54ffdc
USA #1
I'm willing to bet that you're freeing something twice somewhere, or freeing an invalid pointer.
USA #2
3589            extracted_obj_queue = extracted_obj_queue->next;
3590        STRFREE( obj->name        );
3591        STRFREE( obj->description );
3592        STRFREE( obj->short_descr );
3593        STRFREE( obj->action_desc );
3594        DISPOSE( obj );
3595            --cur_qobjs;


(gdb) p *obj
$1 = {next = 0x54fd3c, prev = 0x44c826, next_content = 0x0, prev_content = 0x5285f0, first_content = 0x4981d0,
  last_content = 0x498860, in_obj = 0x498350, carried_by = 0x498570, first_extradesc = 0x42cfd0, last_extradesc = 0x49a6a0,
  first_affect = 0x0, last_affect = 0x0, pIndexData = 0x0, in_room = 0x0, name = 0x0, short_descr = 0x0, description = 0x0,
  action_desc = 0x1 "", item_type = 895, mpscriptpos = 0, extra_flags = {bits = {33, 64, 0, 0}}, magic_flags = 0,
  wear_flags = 0, mpact = 0x3, mpactnum = -1726662223, wear_loc = -17181, weight = 5797, cost = 1735697613, level = 20766,
  timer = 15873, value = {1313901226, 1627687941, -179304937, -2073333483, 1780058412, -1989503057}, count = -1738,
  serial = 344556628, room_vnum = 939512070, ashards = -100, creator = 0x59e17104 <Address 0x59e17104 out of bounds>}


Or could that be a problem? I haven't changed clean_obj_queue.
USA #3
I don't see a problem in there. Again, I'm quite sure that something somewhere is being freed twice, which will make malloc (free) very unhappy.

If you have valgrind lying around, use it. :P
USA #4
This is the first time it's happened in the last 4 months. I don't think I'll be attaching valgrind to it for months. Unless I can attach it to the core? Doubt it.

[EDIT] Oh well, I'm not worried about this unless it happens again in the next month.
Amended on Sun 12 Dec 2004 08:59 PM by Zeno
Canada #5
I've come across something similiar, make sure that your DISPOSE and STRFREE macros NULL the pointer passed to them, as I beleive its not by default, this will help many things in the future.