20 Jan, 2015, koqlb wrote in the 2nd comment:
Might I add this happens generally around the time a tick is going to happen if you start writing a note.
20 Jan, 2015, plamzi wrote in the 3rd comment:
Valgrind output can be overwhelming and unhelpful in this case. What does gdb have to say?
21 Jan, 2015, Kaz wrote in the 4th comment:
The dump indicates that you're reading through an invalid pointer in p_act_trigger. Perhaps something in your notes system is corrupting whatever variable happens to be eventually read in that function, and thus it only happens later when a particular mob proc is triggered? What's mob_prog.c:2184
21 Jan, 2015, Tijer wrote in the 5th comment:
i had similar issues when i put the snippet in a Rot based mud.. I sorted the issue, when i remember what i did i will share :)
22 Jan, 2015, koqlb wrote in the 6th comment:
The bit of code in mob_prog.c is as follows:
And again, in the gdb output, it mentions 2184. But this problem has been in since BEFORE the whole prog_trigger was in:
????????
if ( mob )
{
for ( prg = mob->pIndexData->mprogs; prg != NULL; prg = prg->next ) /* Line 2184 */
{
if ( prg->trig_type == type
&& strstr( argument, prg->trig_phrase ) != NULL )
{
program_flow( prg->vnum, prg->code, mob, NULL, NULL, ch, arg1, arg2 );
break;
}
}
}
And again, in the gdb output, it mentions 2184. But this problem has been in since BEFORE the whole prog_trigger was in:
Program received signal SIGSEGV, Segmentation fault.
0x000000000046615f in p_act_trigger (
argument=0x7fffffffd0f0 "The healer utters the word 'fido'.\n\r",
mob=0x7ffff7264bd0, obj=0x0, room=0x0, ch=0x7ffff737e038, arg1=0x0,
arg2=0x0, type=1) at mob_prog.c:2184
2184 for ( prg = mob->pIndexData->mprogs; prg != NULL; prg = prg->next )
????????
22 Jan, 2015, SlySven wrote in the 7th comment:
Call me paranoid but what is the value of mob->pIndexData at the time it crashes? If THAT is NULL attempting to dereference it to get mob->pIndexData->mprogs is not going to end well!
22 Jan, 2015, koqlb wrote in the 8th comment:
Player doesn't switch to a mob, but the player DOES however go to CON_NOTE_EDIT in nanny.c due to the Erwin note board system. The mob does not become null, but is the healer vnum 3012
And it's a spec_healer. However, when you go into a different CON state, you don't actually see, as you're no longer "playing"… Hrm…. I wonder if I answered my own question and found the stupid problem.
Maybe if I take out the CON_NOTE_WRITE, POST, and switch, and just keep the player playing, but still call the actual FUNCTIONS for con_note_handler it may work? Diablos… Where ya at? lol.
And it's a spec_healer. However, when you go into a different CON state, you don't actually see, as you're no longer "playing"… Hrm…. I wonder if I answered my own question and found the stupid problem.
Maybe if I take out the CON_NOTE_WRITE, POST, and switch, and just keep the player playing, but still call the actual FUNCTIONS for con_note_handler it may work? Diablos… Where ya at? lol.
22 Jan, 2015, SlySven wrote in the 9th comment:
Perhaps I'm missing something (a sense of humour :lol:) but gdb is telling you that there is a segmentation fault on line 2184 which you have kindly indicated:
for ( prg = mob->pIndexData->mprogs; prg != NULL; prg = prg->next ) /* Line 2184 */we know from the previous:
if( mob )that mob is not zero but the segment of code shown does not tell me (who to be honest is totally unfamiliar with the code) that mob->pIndexData points at anything and if it doesn't (or does not point to anything meaningful) then trying to dereference it to get the value pointed to in the mprogs member is going to crash and burn, a.k.a. Segmentation Fault (which I hope anyone working from the Dummy's Guide to 'C' programming will remember means: attempting to access a memory address outside of permitted range) - which is what seems to be happening isn't it?
22 Jan, 2015, Tijer wrote in the 10th comment:
The problem lies in the act function… Erwins note system tells you to add a line to stop output when connected state does not equal con_playing… The reason it is crashing COULD be due to the fact that it's checking for connected state on the mobile running the mob prog… I still cannot remember what I did to fix this issue on my mud….
22 Jan, 2015, Kaz wrote in the 11th comment:
mob->pIndexData could be an invalid or NULL pointer. How could this happen? How could a mob get an invalid or NULL pIndexData?
My best guess is that you are looking at a mob that has been deleted. It has been removed, and its data has been freed and zeroed out … and has not been removed from the mob list.
My best guess is that you are looking at a mob that has been deleted. It has been removed, and its data has been freed and zeroed out … and has not been removed from the mob list.
22 Jan, 2015, Tijer wrote in the 12th comment:
Worked out the fix you need to put the following line in
in void act in comm.c… and any other function that works similarly to act! :)
for ( ; to ; to = to->next_in_room )
{
if (to->desc != NULL && to->desc->connected != CON_PLAYING) <<This line
continue; <<This line
if ( (!IS_NPC(to) && to->desc == NULL )
|| ( IS_NPC(to) && to->desc == NULL && !HAS_TRIGGER_MOB(to, TRIG_ACT) )
|| to->position < min_pos
|| ( type == TO_CHAR && to != ch )
|| ( type == TO_VICT && ( to != vch || to == ch ) )
|| ( type == TO_ROOM && to == ch )
|| ( type == TO_NOTVICT && ( to == ch || to == vch ) ) )
continue;
if ( (type == TO_ROOM || type == TO_NOTVICT)
&& !IS_NPC(ch) && !IS_NPC(to)
&& ch->in_room != NULL && to->in_room != NULL
&& IS_SET(ch->in_room->room_flags,ROOM_ARENA)
&& IS_SET(to->in_room->room_flags,ROOM_ARENA)
&& ch->pcdata->match != to->pcdata->match )
continue;
in void act in comm.c… and any other function that works similarly to act! :)
22 Jan, 2015, Davion wrote in the 13th comment:
koqlb said:
The bit of code in mob_prog.c is as follows:
if ( mob )
{
for ( prg = mob->pIndexData->mprogs; prg != NULL; prg = prg->next ) /* Line 2184 */
{
if ( prg->trig_type == type
&& strstr( argument, prg->trig_phrase ) != NULL )
{
program_flow( prg->vnum, prg->code, mob, NULL, NULL, ch, arg1, arg2 );
break;
}
}
}
Sounds trivial, but make sure mob->pIndexData->mprogs is properly NULL'd on creation. Sometimes they are simply uninitialized. When they are recycled they don't get properly zero'd too. Easiest way to do it is to allocate with calloc(). Also make sure pIndexData is properly NULL'd when mob is allocated.
22 Jan, 2015, koqlb wrote in the 14th comment:
Tjier had it right, only that QuickMUD does not have a "void act" function anymore. Instead it has void act_new. :) Thanks Tjier, I tested it and had luck (of course players will hate seeing act messages while writing notes, but oh well. Small sacrifice to keep the MUD going).
23 Jan, 2015, SlySven wrote in the 15th comment:
@Davion & Kaz: I guess he isn't listening or hasn't heard of defensive programming, of course in 'C' using pointers from code that you do not know to be contractually correct or validated yourself enables you to shoot yourself in both feet, sigh…
23 Jan, 2015, Tijer wrote in the 16th comment:
i agree my fix was a hacky fix.. but it stopped the crashes.. :P BTW Koqlb, your players shouldnt see act messages still while connected state is less than con_playing :)
23 Jan, 2015, koqlb wrote in the 17th comment:
I'm fixing those issues as well. Mobprogs are now successfully nulled on creation as well. However, the true issue was that when the healer would cast a spell (the player would be at vnum 3054 on a stock ROM, which is the healer's temple), then since you were in a different CON state, you would get no act messages, so it was trying to output act or act_new messages in comm.c to a player who was in a CON_NOTE state and failing. But I added the checks to fix the line as well. And when I ran valgrind I had no errors and no leaks. :) So thanks everybody.
23 Jan, 2015, Tijer wrote in the 18th comment:
depends how your connected states work.. usually con_playing is the highest connected state….. well is on muds ive worked on anyways…
Random Picks
It happens randomly, and though it's while USING the note board system, when a player tries to write a note, as soon as they can start writing (I use the append_editor, but this problem has been happening since before that), boom, it crashes. I've used valgrind with all options minus the gdb (I stayed on to see what was going on with it). I don't know what keeps making the player do this. I do know it's Erwin's Board system which still uses the CON_NOTE states in nanny.c.
Here's the Valgrind on SegFault:
Now this only happens it seems when it's a player in which I've ploaded, then validated, then unloaded. Here's the punload code:
I also just realized this function has no return at the end, which I will fix.
Here's my validate command:
O.o This bug has been since I STARTED the QuickMUD and put the pload and punload function in. I don't know where the problem is. If it's my board.c file, then that is located on a redundant post here: http://www.mudbytes.net/topic-4672
I just want to get to the bottom of this. I'm wondering if it has something to do with the punload function's call to save and extract the character.