Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
tintin++ ogg sound player script for linux
Author: Robert Smith
Submitted by: Vladaar
6Dragons ogg Soundpack
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.4
Author: Vladaar
Submitted by: Vladaar
LoP 1.46
Author: Remcon
Submitted by: Remcon
LOP 1.45
Author: Remcon
Submitted by: Remcon
Users Online
CommonCrawl, Sogou, Yandex

Members: 0
Guests: 6
Stats
Files
Topics
Posts
Members
Newest Member
481
3,735
19,370
618
Micheal64X
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » General » Coding » clean_obj_queue issues
Forum Rules | Mark all | Recent Posts

clean_obj_queue issues
< Newer Topic :: Older Topic > segfaults :(

Pages:<< prev 1 next >>
Post is unread #1 Aug 4, 2009, 1:31 pm
Go to the top of the page
Go to the bottom of the page

Syriac
Fledgling
GroupMembers
Posts12
JoinedJul 14, 2009

I recently re-discovered I had commented out the call to this function, not recalling why I tried to put it back in with disasterous results. I tried to patch in some of the SMAUG 1.8 code for this but it doesn't appear to work. For some reason its passing an unacceptable value through the function and I can't figure out why. :(

Program received signal SIGSEGV, Segmentation fault.
0x000000324207725a in _int_free () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.10.1-2.x86_64 nss-softokn-freebl-3.12.3.99.3-2.11.3.fc11.x86_64 zlib-1.2.3-22.fc11.x86_64
(gdb) bt
#0  0x000000324207725a in _int_free () from /lib64/libc.so.6
#1  0x00000000004e5cc3 in free_obj (obj=0x109bc00) at handler.c:6892
#2  0x00000000004e5965 in clean_obj_queue () at handler.c:6841
#3  0x0000000000582f95 in update_handler () at update.c:3554
#4  0x00000000004a2835 in game_loop () at comm.c:716
#5  0x00000000004a1d8c in main (argc=1, argv=0x7fffffffe6c8) at comm.c:343


in handler.c
/* borrowed from smaug 1.8 */
void clean_obj_queue( void )
{
   OBJ_DATA *obj;

   while( extracted_obj_queue )
   {
      obj = extracted_obj_queue;
      extracted_obj_queue = extracted_obj_queue->next;
      free_obj( obj );
      --cur_qobjs;
   }
}

/* Deallocates the memory used by a single object after it's been extracted. */
void free_obj( OBJ_DATA * obj )
{
   AFFECT_DATA *paf, *paf_next;
   EXTRA_DESCR_DATA *ed, *ed_next;
   // REL_DATA *RQueue, *rq_next;
   MPROG_ACT_LIST *mpact, *mpact_next;

    if( !obj ) {
        bug( "%s: obj = NULL", __FUNCTION__ );
        return; }


   for( mpact = obj->mpact; mpact; mpact = mpact_next )
   {
      mpact_next = mpact->next;
      DISPOSE( mpact->buf );
      DISPOSE( mpact );
   }
   /*
    * remove affects
    */
   for( paf = obj->first_affect; paf; paf = paf_next )
   {
      paf_next = paf->next;
      DISPOSE( paf );
   }
   obj->first_affect = obj->last_affect = NULL;

   /*
    * remove extra descriptions
    */
   for( ed = obj->first_extradesc; ed; ed = ed_next )
   {
      ed_next = ed->next;
      STRFREE( ed->description );
      STRFREE( ed->keyword );
      DISPOSE( ed );
   }  
   obj->first_extradesc = obj->last_extradesc = NULL;

   STRFREE( obj->name );
   STRFREE( obj->description );
   STRFREE( obj->short_descr );
   STRFREE( obj->action_desc );
   DISPOSE( obj );  //<---Crash originates here.
   return;
}



call to function in update.c is clean_obj_queue( );
       
Post is unread #2 Aug 6, 2009, 7:29 am   Last edited Aug 6, 2009, 7:30 am by Darrik
Go to the top of the page
Go to the bottom of the page

Darrik
Fledgling
GroupMembers
Posts20
JoinedJan 29, 2008

free() crashes suck, sometimes. If I'm counting line numbers right, you are crashing on STRFREE( ed->keyword ); ?? if I miscounted, then the causes are the same, and the problem could be in a variety of places anyway.

Two possibilities are that:

1) You have already deleted the memory that pointer directs to, and not NULL'd the pointer. That would happen if you are free()ing a STRALLOC'd variable.

2) You are trying to STRFREE something you did not STRALLOC. Although the stock code everywhere I've checked STRALLOC's that variable, it's easy enough to make a mistake on something like that and not use the hashing.

-- Both of those possibilities above are the easiest causes of memory leaks in smaug. And memory leaks are often very difficult to track down. I'd say the first possibility is more likely... the problem may not lie in the extra description code at all... if you free()'d the same string as that keyword happens to be, somewhere in your code, it'll cause that crash.
       
Post is unread #3 Aug 6, 2009, 6:32 pm
Go to the top of the page
Go to the bottom of the page

Syriac
Fledgling
GroupMembers
Posts12
JoinedJul 14, 2009

(gdb) p *obj
$1 = {next = 0xf27750, prev = 0x10879e0, next_content = 0x0, prev_content = 0xf25ad0, first_content = 0x0, last_content = 0x0, 
  in_obj = 0x0, carried_by = 0x0, originator = 0x0, ownerorig = 0x0, first_extradesc = 0x0, last_extradesc = 0x0, first_affect = 0x0, 
  last_affect = 0x0, affected = 0x0, pIndexData = 0x9c3940, in_room = 0x0, name = 0x0, short_descr = 0x0, description = 0x0, 
  id_mark = 0x0, action_desc = 0x0, item_type = 1, mpscriptpos = 0, extra_flags = {bits = {0, 0, 0, 0}}, magic_flags = 0, wear_flags = 1, 
  mpact = 0x0, mpactnum = 0, wear_loc = -1, weight = 1, cost = 0, level = 1, tmag = 0, timer = 0, value = {0, 0, -1, 0, 0, 0}, count = 1, 
  serial = 3766, room_vnum = 0}
(gdb) 


I'm just not seeing it and I'm going nuts... blahhh.
       
Post is unread #4 Aug 7, 2009, 6:34 am   Last edited Aug 7, 2009, 7:12 am by Darrik
Go to the top of the page
Go to the bottom of the page

Darrik
Fledgling
GroupMembers
Posts20
JoinedJan 29, 2008

Found this:

http://www.gammon.com.au/forum/?id=5017

Apparently it's happened before. Does this happen everytime, or is it one of the many 'fluke' crashes in Smaug?

Edit: For that matter, looks like you've got a thread on the gammon forum.

I'm getting cross-eyed.

Best suggestion I can come up with is check to make sure you are not DISPOSE'ing of an object before or while you put it on the delete queue. You could always go through every call to DISPOSE or free you can grep and verify you aren't performing one on an object, or if you are, why?
       
Post is unread #5 Aug 7, 2009, 11:28 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

There's every chance this was "one of those things" like the room_is_dark bug that ended up fixed without knowing how. The kind of bugs that annoy persistently until one day they just vanish never to be heard from again. Always leaves you wondering just what it was that fixed it.

Beyond making sure the macros are sound, there's not much else to go on because the only bugfix for this was when the free_obj() function was added to clean up the memory leaks the stock code left behind when clean_obj_queue was called.
       
Post is unread #6 Aug 7, 2009, 12:48 pm
Go to the top of the page
Go to the bottom of the page

Syriac
Fledgling
GroupMembers
Posts12
JoinedJul 14, 2009

Okay I think I have it fixed, pretty sure it was just clearing a value twice... so far so good.
       
Post is unread #7 Aug 7, 2009, 12:50 pm
Go to the top of the page
Go to the bottom of the page

Darrik
Fledgling
GroupMembers
Posts20
JoinedJan 29, 2008


Details, details :)
       
Post is unread #8 Aug 7, 2009, 2:29 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

Details indeed, it would be nice to know what might have triggered this so we can note it for later.
       
Post is unread #9 Aug 9, 2009, 3:08 am
Go to the top of the page
Go to the bottom of the page

Syriac
Fledgling
GroupMembers
Posts12
JoinedJul 14, 2009

sadly i jumped the gun, while it does run a few minutes longer than it did before it eventually crashes. it has consumed too much time of mine and i've accomplished nothing in hindsight so I've just decided to forego the process all together, while it is sloppy it isn't the end of the world. rebooting daily cleans things up. sad that its so touchy though. wish I knew what the hell caused it, the furthest I could narrow things down to was the dispose function just is broken :-/
       
Post is unread #10 Aug 9, 2009, 3:45 am
Go to the top of the page
Go to the bottom of the page

Syriac
Fledgling
GroupMembers
Posts12
JoinedJul 14, 2009

new theory, i am starting to think that it is because my random item generator set shorts/names/longs/descs with the str_dup function vice STRALLOC... recompiling and praying.
       
Post is unread #11 Aug 9, 2009, 3:50 am
Go to the top of the page
Go to the bottom of the page

Syriac
Fledgling
GroupMembers
Posts12
JoinedJul 14, 2009

could it really be this simple? :stare:
       
Post is unread #12 Aug 9, 2009, 4:03 am
Go to the top of the page
Go to the bottom of the page

Syriac
Fledgling
GroupMembers
Posts12
JoinedJul 14, 2009

Fixed, wow how did I over look that.
       
Post is unread #13 Aug 9, 2009, 11:46 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

Syriac said:

new theory, i am starting to think that it is because my random item generator set shorts/names/longs/descs with the str_dup function vice STRALLOC... recompiling and praying.


This is what the new STRFREE and DISPOSE macros are supposed to help spot. If you're able to compile with g++ and use the updated macros it should be firing off a warning whenever an attempt is made to use the wrong one to deallocate a string. It may not immediately pinpoint the cause but should at least help narrow down where to look.
       
Post is unread #14 Aug 10, 2009, 6:41 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

How are the new macros able to tell if it's a shared string or not?
       
Post is unread #15 Aug 10, 2009, 11:55 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

There's a function added to the code to look through the string hash to see if the string is there or not. DISPOSE looks to see if it is, issues a warning, then attempts to do what STRFREE does. STRFREE checks to see if it's NOT there, and if it isn't issues a warning and tries to perform what DISPOSE would do.

When I put them in originally it led to finding a few stray bugs of this nature but it's been ages since I've seen a running game throw one now. I'm surprised it didn't get tripped in this case because this is exactly what the altered macros should be detecting.
       
Post is unread #16 Aug 11, 2009, 9:15 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

You mean every single call to DISPOSE does a traversal of the shared string table?

Sheesh... and to think that all of these problems would have gone away if there had been proper type safety with these strings in the first place. :thinking:
       
Post is unread #17 Aug 11, 2009, 12:59 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

Proper type safety in what way? It would still seem possible to me to call the wrong allocation command no matter how safe things are. Macro hacks wouldn't be necessary at all if there weren't two ways to handle strings strewn about the code :)
       
Post is unread #18 Aug 11, 2009, 1:58 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

I was referring to something like a C++ object with a destructor that handles this for you when the string object is destroyed, instead of having to manually free the objects. Maybe "type safety" wasn't the best word, though...
       
Pages:<< prev 1 next >>