06 Apr, 2009, Lancsta wrote in the 1st comment:
Votes: 0
So a few years ago I was having some odd crashes, get em every few weeks, and then they just disappeared. Well they are back again and I'm having issues trying to spot what's actually the problem. I've been able to get a few reports from gdb but still can't see what's going on. Seeing as how the functions actually work and can't recreate the crash. I was in a hurry with this one and didn't print anything.

0x000d4a78 in gain_condition (ch=0x217d804, iCond=0, value=-1) at update.c:472
472 condition = ch->pcdata->condition[iCond];

#0 0x000d4a78 in gain_condition (ch=0x217d804, iCond=0, value=-1) at update.c:472
#1 0x000d6258 in char_update () at update.c:1304
#2 0x00043220 in sig_handler (sig=10) at comm.c:3511
#3 <signal handler called>
#4 0x000d5d10 in underwater_update () at update.c:1481
#5 0x000d75ec in update_handler () at update.c:2055
#6 0x00048800 in game_loop_unix (mud_desc=5) at comm.c:538
#7 0x00048d04 in main (argc=1280688, argv=0x23fc90) at comm.c:295

That's one of them I'll post another after I get a better gdb out of it.
06 Apr, 2009, Kline wrote in the 2nd comment:
Votes: 0
Well, next time you get a crash; is ch actually a PC, or an NPC? Are you calling gain_condition() on somebody after they've been extracted? I see you have an underwater_update() – is it possible for a person to drown, get extract_char() called on them, and not be properly removed from a list someplace? All things to check based on the limited info so far.
06 Apr, 2009, Keberus wrote in the 3rd comment:
Votes: 0
I agree with Kline, my first guess would be that it's trying to update an NPC's condition through underwater_update, if so, then all you need to do is throw in a check for it to skip of NPCs.
06 Apr, 2009, Lancsta wrote in the 4th comment:
Votes: 0
Yeah I looked a little closer to what was going on and changed it to the one at the bottom. I found another place in char_update we changed it from char_list to descriptor.
void underwater_update( void )
CHAR_DATA *ch_next;

for ( ch = char_list; ch != NULL; ch = ch_next)
ch_next = ch->next;

void underwater_update( void )

for ( d = descriptor_list; d; d = d->next )
if ( d->connected != CON_PLAYING )
ch = d->original ? d->original : d->character;

Thank you.
07 Apr, 2009, Lancsta wrote in the 5th comment:
Votes: 0
This is another one that popped in around the same time yesterday. Also I noticed that when these happened it was from characters that hadn't logged in for quite some time.

#0  0x00077898 in affect_modify (ch=0x15ee430, paf=0x42abf90, fAdd=0 '\0') at handler.c:1456
#1 0x000780e8 in affect_remove (ch=0x15ee430, paf=0x42abf90) at handler.c:1776
#2 0x000d644c in char_update () at update.c:1351
#3 0x000d75a8 in update_handler () at update.c:2043
#4 0x00048800 in game_loop_unix (mud_desc=5) at comm.c:538
#5 0x00048d04 in main (argc=1280688, argv=0x240c90) at comm.c:295
(gdb) list
1451 {
1452 if ( ( tmp != paf ) && ( tmp->bitvector == paf->bitvector ) && ( tmp->where == paf->where ) )
1453 duplicate = TRUE;
1454 break;
1455 }
1456 for ( tmp = objtmp->pIndexData->affected;
1457 tmp != NULL; tmp = tmp->next )
1458 {
1459 if ( ( tmp != paf ) && ( tmp->bitvector == paf->bitvector ) && ( tmp->where == paf->where ) )
1460 duplicate = TRUE;
(gdb) up
#1 0x000780e8 in affect_remove (ch=0x15ee430, paf=0x42abf90) at handler.c:1776
1776 affect_modify ( ch, paf, FALSE );
(gdb) list
1771 {
1772 bugf ( "Affect_remove: no affect." );
1773 return;
1774 }
1776 affect_modify ( ch, paf, FALSE );
1778 if ( paf == ch->affected )
1779 {
1780 ch->affected = paf->next;
(gdb) up
#2 0x000d644c in char_update () at update.c:1351
l1351 affect_remove ( ch, paf );
is(gdb) list
1346 }
1347 }
1348 /* Zeran - undo masked descriptions */
1349 if ( paf->bitvector == AFF_POLY )
1350 undo_mask ( ch );
1351 affect_remove ( ch, paf );
1352 }
1353 }
1355 /*
07 Apr, 2009, Sharmair wrote in the 6th comment:
Votes: 0
You don't really give much info here, not enough to really be sure anyway. But from the line
it is crashing on, I would say the most probable problem would be if objtmp is NULL or invalid.
You put this in the ROM forum, but ROM (and really no codebases I know of) has any code
like this in affect_modify() and you don't give enough of the code preceding the problem to
give the full context of how this part of the code (and objtmp) is used.

About the only things that would cause the line:
for ( tmp = objtmp->pIndexData->affected;

To crash are if objtmp or objtmp->pIndexData point to invalid memory. You could try
'print objtmp' and 'print *objtmp' in gdb (in frame 0 of course) and see what it looks like.
08 Apr, 2009, Lancsta wrote in the 7th comment:
Votes: 0
It's Sunder, rom based. I'll see what I can do to recreate it and print that in gdb. I'm still trying to figure out gdb. Like where the error happened and what not. I'll try to gather more info before I post again, sorry about that.
08 Apr, 2009, Lancsta wrote in the 8th comment:
Votes: 0
void affect_remove ( CHAR_DATA * ch, AFFECT_DATA * paf )
if ( ch->affected == NULL )
bugf ( "Affect_remove: no affect." );

affect_modify ( ch, paf, FALSE );

if ( paf == ch->affected )
ch->affected = paf->next;

for ( prev = ch->affected; prev != NULL; prev = prev->next )
if ( prev->next == paf )
prev->next = paf->next;

if ( prev == NULL )
bugf ( "Affect_remove: cannot find paf." );

paf->next = affect_free;
// affect_free = paf;
affect_free = paf->next;

I noticed this when I was browsing through affect_remove. I'm thinking that's probably got something to do with it. I found another code base that had the same function and compared the code.

//     affect_free = paf;
affect_free = paf->next;
08 Apr, 2009, ghasatta wrote in the 9th comment:
Votes: 0
I think that code you highlighted will result in a memory leak, as the affect to be freed just sort of goes off into the ether. Don't think that would result in a seg fault though.

Additionally, the call to affect_modify() is fairly high up in the affect_remove() function, so there isn't a whole lot of opportunity for something to go wrong before affect_modify() is called. What does that function look like?
08 Apr, 2009, Lancsta wrote in the 10th comment:
Votes: 0
It was uh, rather large so I put it up here.
08 Apr, 2009, Sharmair wrote in the 11th comment:
Votes: 0
As far as the code at the end of affect_remove(), I have no idea why the line was changed.
The commented out line is the one you would want. The line after that makes no sense at
all as it is redundant (it is setting a variable with the value it already has) and should be

From the code you posted for affect_modify() and some of the stuff you mentioned about
who the crash seems to happen with, I would guess that your code allows objects with no
index. In most codebases, that is a condition that can not happen. I would look in your
object loading code for player files, and make sure if the player has an object that no longer
exists, the code either clean up (and delete) the incomplete object or set the index to some
default index. My guess is that the players are ending up with an incomplete object with
a NULL or invalid pIndexData (the pointer to the index) if the pfile has an object of a
nonexistent vnum.