Requesting a plumber?

Posted by Findecano on Sat 03 Nov 2007 11:50 PM — 7 posts, 28,073 views.

#0
Ok so I think I got a leak somewhere but I'm not sure what it could be. I think it might be something to do with a bit which I added called "IslandName" which worked fine previously on SmaugFUSS 1.7 and I believe I have everything correct.

Just wondering if you guys got any ideas?



==31155== Invalid read of size 4
==31155==    at 0x80BBB41: close_area(area_data*) (act_wiz.c:5912)
==31155==    by 0x80BBD84: close_all_areas() (act_wiz.c:5931)
==31155==    by 0x810D9D5: cleanup_memory() (comm.c:318)
==31155==    by 0x810E708: main (comm.c:559)
==31155==  Address 0x431305C is 4 bytes inside a block of size 156 free'd
==31155==    at 0x4004EFA: free (vg_replace_malloc.c:235)
==31155==    by 0x80BBD1C: close_area(area_data*) (act_wiz.c:5916)
==31155==    by 0x80BBD58: close_all_areas() (act_wiz.c:5926)
==31155==    by 0x810D9D5: cleanup_memory() (comm.c:318)
==31155==    by 0x810E708: main (comm.c:559)


#0  0x005fc7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x0063d7a5 in raise () from /lib/tls/libc.so.6
#2  0x0063f209 in abort () from /lib/tls/libc.so.6
#3  0x00671a1a in __libc_message () from /lib/tls/libc.so.6
#4  0x006782bf in _int_free () from /lib/tls/libc.so.6
#5  0x0067863a in free () from /lib/tls/libc.so.6
#6  0x080bbd1d in close_area (pArea=0xa38dcf0) at act_wiz.c:5916
#7  0x080bbd85 in close_all_areas () at act_wiz.c:5931
#8  0x0810d9d6 in cleanup_memory () at comm.c:318
#9  0x0810e709 in main (argc=1, argv=0xbfec7684) at comm.c:559


(gdb) frame 6
#6  0x080bbd1d in close_area (pArea=0xa38dcf0) at act_wiz.c:5916
5916       DISPOSE( pArea );
Current language:  auto; currently c++
(gdb) frame 7
#7  0x080bbd85 in close_all_areas () at act_wiz.c:5931
5931          close_area( area );
(gdb) frame 8
#8  0x0810d9d6 in cleanup_memory () at comm.c:318
318        close_all_areas(  );
(gdb) frame 9
#9  0x0810e709 in main (argc=1, argv=0xbfec7684) at comm.c:559
559        cleanup_memory(  );
USA #1
It's telling you that at line 5912, you are trying to free something that you already freed on line 5916.
#2

   DISPOSE( pArea->islandname );
   if( IS_SET( pArea->flags, AFLAG_PROTOTYPE ) )
   {
      UNLINK( pArea, first_build, last_build, next, prev );
      UNLINK( pArea, first_bsort, last_bsort, next_sort, prev_sort );
   }
   else
   {
(line 5912)      UNLINK( pArea, first_area, last_area, next, prev );
      UNLINK( pArea, first_asort, last_asort, next_sort, prev_sort );
      UNLINK( pArea, first_area_name, last_area_name, next_sort_name, prev_sort_name );
   }
(line 5916)   DISPOSE( pArea );
}


Hmmm, any ideas?
USA #3
One thing I would try is a make clean followed by make. When you add fields to structures but don't rebuild all the object files, things can get pretty confused about how to properly free them.
#4
Heh. No luck.. im still getting burst pipes =P

hmmm, Its living me completely clueless on what could be causing it. Any other thoughts? I'm also getting a bunch of core dumps.. which is being causes when it seems to be trying to close areas. Could that be a cause of disposing of data incorrectly? Or any other means?

Cheers for any help anyway.
USA #5
Yeah, somehow you've managed to either corrupt the memory or free something twice. Valgrind is telling you that you freed something twice, so it's probably right. If you're not actually seeing two 'free' lines in the code, what probably happened is that you put the area into the area list twice, and so as it's looping over the areas freeing them, it is unwittingly freeing it twice.

(But keep in mind the make-clean business: if you don't "refresh" the object code, it can make for serious trouble...)
USA #6
The only way I can see this happening is if the area being closed is on both the regular zone list and the prototype zone list. This seems to be further supported by the fact that it crashes in close_all_areas() which is only called at a shutdown or reboot, and walks both lists to remove areas from them.