20 Jan, 2015, koqlb wrote in the 1st comment:
Votes: 0
Okay, so I've recently discovered a problem I've had usingi the Erwin's board system. I thought it was because I'd pload the player, validate them offline, then punload them.
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:
Mon Jan 19 21:18:36 2015 :: Valitar@72.47.116.193 has connected.
==16614== Invalid read of size 8
==16614== at 0x46615F: p_act_trigger (mob_prog.c:2184)
==16614== by 0x425933: act_new (comm.c:2618)
==16614== by 0x4590C8: spec_cast_adept (special.c:579)
==16614== by 0x45A40C: mobile_update (update.c:448)
==16614== by 0x45B5CB: update_handler (update.c:1248)
==16614== by 0x427804: game_loop_unix (comm.c:950)
==16614== by 0x427D16: main (comm.c:463)
==16614== Address 0x18 is not stack'd, malloc'd or (recently) free'd
==16614==
Mon Jan 19 21:20:09 2015 :: Segmentation violation Caught, restarting Game Loop
==16614== Invalid read of size 8
==16614== at 0x46615F: p_act_trigger (mob_prog.c:2184)
==16614== by 0x425933: act_new (comm.c:2618)
==16614== by 0x458FCC: spec_cast_adept (special.c:559)
==16614== by 0x45A40C: mobile_update (update.c:448)
==16614== by 0x45B5CB: update_handler (update.c:1248)
==16614== by 0x427804: game_loop_unix (comm.c:950)
==16614== by 0x4279E1: segv_handle (comm.c:553)
==16614== by 0x50981DF: ??? (in /lib/x86_64-linux-gnu/libc-2.13.so)
==16614== by 0x46615E: p_act_trigger (mob_prog.c:2184)
==16614== by 0x425933: act_new (comm.c:2618)
==16614== Address 0x18 is not stack'd, malloc'd or (recently) free'd
==16614==
==16614==
==16614== Process terminating with default action of signal 11 (SIGSEGV)
==16614== Access not within mapped region at address 0x18
==16614== at 0x46615F: p_act_trigger (mob_prog.c:2184)
==16614== by 0x425933: act_new (comm.c:2618)
==16614== by 0x458FCC: spec_cast_adept (special.c:559)
==16614== by 0x45A40C: mobile_update (update.c:448)
==16614== by 0x45B5CB: update_handler (update.c:1248)
==16614== by 0x427804: game_loop_unix (comm.c:950)
==16614== by 0x4279E1: segv_handle (comm.c:553)
==16614== by 0x50981DF: ??? (in /lib/x86_64-linux-gnu/libc-2.13.so)
==16614== by 0x46615E: p_act_trigger (mob_prog.c:2184)
==16614== by 0x425933: act_new (comm.c:2618)
==16614== If you believe this happened as a result of a stack
==16614== overflow in your program's main thread (unlikely but
==16614== possible), you can try to increase the size of the
==16614== main thread stack using the –main-stacksize= flag.
==16614== The main thread stack size used in this run was 8388608.
–16614– Discarding syms at 0x5c2a180-0x5c31148 in /lib/x86_64-linux-gnu/libnss_files-2.13.so due to munmap()
–16614– Discarding syms at 0x5e35000-0x5e37fc8 in /lib/x86_64-linux-gnu/libnss_dns-2.13.so due to munmap()
–16614– Discarding syms at 0x603d8c0-0x6049998 in /lib/x86_64-linux-gnu/libresolv-2.13.so due to munmap()
==16614==
==16614== FILE DESCRIPTORS: 8 open at exit.
==16614== Open file descriptor 3: /dev/null
==16614== at 0x51365E0: __open_nocancel (syscall-template.S:82)
==16614== by 0x50D95C0: _IO_file_open (fileops.c:232)
==16614== by 0x50D972A: _IO_file_fopen@@GLIBC_2.2.5 (fileops.c:336)
==16614== by 0x50CE305: __fopen_internal (iofopen.c:93)
==16614== by 0x47F91B: who_html_update (webwho.c:197)
==16614== by 0x45B5F2: update_handler (update.c:1255)
==16614== by 0x427804: game_loop_unix (comm.c:950)
==16614== by 0x4279E1: segv_handle (comm.c:553)
==16614== by 0x50981DF: ??? (in /lib/x86_64-linux-gnu/libc-2.13.so)
==16614== by 0x46615E: p_act_trigger (mob_prog.c:2184)
==16614==
==16614== Open AF_INET socket 6: 24.222.84.75:5680 <-> 72.47.116.193:63091
==16614== at 0x51433F0: __accept_nocancel (syscall-template.S:82)
==16614== by 0x4270A3: init_descriptor (comm.c:1042)
==16614== by 0x42755A: game_loop_unix (comm.c:861)
==16614== by 0x427D16: main (comm.c:463)
==16614==
==16614== Open AF_INET socket 8: 24.222.84.75:5680 <-> 72.47.116.193:63084
==16614== at 0x51433F0: __accept_nocancel (syscall-template.S:82)
==16614== by 0x4270A3: init_descriptor (comm.c:1042)
==16614== by 0x42755A: game_loop_unix (comm.c:861)
==16614== by 0x427D16: main (comm.c:463)
==16614==
==16614== Open AF_INET socket 5: <unbound> <-> unbound
==16614== at 0x51438F7: socket (syscall-template.S:82)
==16614== by 0x427A7D: init_socket (comm.c:485)
==16614== by 0x427CDF: main (comm.c:442)
==16614==
==16614== Open file descriptor 4: ../data/qmconfig.rc
==16614== at 0x51365E0: __open_nocancel (syscall-template.S:82)
==16614== by 0x50D95C0: _IO_file_open (fileops.c:232)
==16614== by 0x50D972A: _IO_file_fopen@@GLIBC_2.2.5 (fileops.c:336)
==16614== by 0x50CE305: __fopen_internal (iofopen.c:93)
==16614== by 0x4189EF: qmconfig_read (act_wiz.c:4924)
==16614== by 0x427CD4: main (comm.c:440)
==16614==
==16614== Open file descriptor 2: /dev/pts/5
==16614== <inherited from parent>
==16614==
==16614== Open file descriptor 1: /dev/pts/5
==16614== <inherited from parent>
==16614==
==16614== Open file descriptor 0: /dev/pts/5
==16614== <inherited from parent>
==16614==
==16614==
==16614== HEAP SUMMARY:
==16614== in use at exit: 8,215,344 bytes in 32 blocks
==16614== total heap usage: 6,152 allocs, 6,120 frees, 10,578,139 bytes allocated
==16614==
==16614== Searching for pointers to 32 not-freed blocks
==16614== Checked 9,172,744 bytes
==16614==
==16614== 568 bytes in 1 blocks are still reachable in loss record 1 of 20
==16614== at 0x4C28BED: malloc (vg_replace_malloc.c:263)
==16614== by 0x50CE2AA: __fopen_internal (iofopen.c:76)
==16614== by 0x4189EF: qmconfig_read (act_wiz.c:4924)
==16614== by 0x427CD4: main (comm.c:440)
==16614==
==16614== 568 bytes in 1 blocks are still reachable in loss record 2 of 20
==16614== at 0x4C28BED: malloc (vg_replace_malloc.c:263)
==16614== by 0x50CE2AA: __fopen_internal (iofopen.c:76)
==16614== by 0x47F91B: who_html_update (webwho.c:197)
==16614== by 0x45B5F2: update_handler (update.c:1255)
==16614== by 0x427804: game_loop_unix (comm.c:950)
==16614== by 0x4279E1: segv_handle (comm.c:553)
==16614== by 0x50981DF: ??? (in /lib/x86_64-linux-gnu/libc-2.13.so)
==16614== by 0x46615E: p_act_trigger (mob_prog.c:2184)
==16614== by 0x425933: act_new (comm.c:2618)
==16614== by 0x4590C8: spec_cast_adept (special.c:579)
==16614==
==16614== 131,072 bytes in 1 blocks are still reachable in loss record 3 of 20
==16614== at 0x4C272B8: calloc (vg_replace_malloc.c:566)
==16614== by 0x4299B0: alloc_perm (db.c:3319)
==16614== by 0x42ED6C: load_mobiles (db2.c:225)
==16614== by 0x42D9DF: boot_db (db.c:423)
==16614== by 0x427CEF: main (comm.c:445)
==16614==
==16614== 131,072 bytes in 1 blocks are still reachable in loss record 4 of 20
==16614== at 0x4C272B8: calloc (vg_replace_malloc.c:566)
==16614== by 0x4299B0: alloc_perm (db.c:3319)
==16614== by 0x44FA32: new_char (recycle.c:279)
==16614== by 0x42AE8C: create_mobile (db.c:2134)
==16614== by 0x42B8EC: reset_room (db.c:1826)
==16614== by 0x42BEE7: reset_area (db.c:2111)
==16614== by 0x42BF54: area_update (db.c:1704)
==16614== by 0x42DB99: boot_db (db.c:469)
==16614== by 0x427CEF: main (comm.c:445)
==16614==
==16614== 131,072 bytes in 1 blocks are still reachable in loss record 5 of 20
==16614== at 0x4C272B8: calloc (vg_replace_malloc.c:566)
==16614== by 0x4299B0: alloc_perm (db.c:3319)
==16614== by 0x44FA32: new_char (recycle.c:279)
==16614== by 0x42AE8C: create_mobile (db.c:2134)
==16614== by 0x42B8EC: reset_room (db.c:1826)
==16614== by 0x42BEE7: reset_area (db.c:2111)
==16614== by 0x42BF54: area_update (db.c:1704)
==16614== by 0x45B543: update_handler (update.c:1223)
==16614== by 0x427804: game_loop_unix (comm.c:950)
==16614== by 0x427D16: main (comm.c:463)
==16614==
==16614== 131,072 bytes in 1 blocks are still reachable in loss record 6 of 20
==16614== at 0x4C272B8: calloc (vg_replace_malloc.c:566)
==16614== by 0x4299B0: alloc_perm (db.c:3319)
==16614== by 0x44FB5E: new_obj (recycle.c:224)
==16614== by 0x42A753: create_object (db.c:2455)
==16614== by 0x42BD89: reset_room (db.c:2039)
==16614== by 0x42BEE7: reset_area (db.c:2111)
==16614== by 0x42BF54: area_update (db.c:1704)
==16614== by 0x45B543: update_handler (update.c:1223)
==16614== by 0x427804: game_loop_unix (comm.c:950)
==16614== by 0x427D16: main (comm.c:463)
==16614==
==16614== 131,072 bytes in 1 blocks are possibly lost in loss record 7 of 20
==16614== at 0x4C272B8: calloc (vg_replace_malloc.c:566)
==16614== by 0x4299B0: alloc_perm (db.c:3319)
==16614== by 0x44F9D2: new_had (recycle.c:662)
==16614== by 0x42D20A: load_helps (db.c:684)
==16614== by 0x42D99B: boot_db (db.c:419)
==16614== by 0x427CEF: main (comm.c:445)
==16614==
==16614== 131,072 bytes in 1 blocks are possibly lost in loss record 8 of 20
==16614== at 0x4C272B8: calloc (vg_replace_malloc.c:566)
==16614== by 0x4299B0: alloc_perm (db.c:3319)
==16614== by 0x42C4A3: load_rooms (db.c:1221)
==16614== by 0x42DACD: boot_db (db.c:437)
==16614== by 0x427CEF: main (comm.c:445)
==16614==
==16614== 131,072 bytes in 1 blocks are possibly lost in loss record 9 of 20
==16614== at 0x4C272B8: calloc (vg_replace_malloc.c:566)
==16614== by 0x4299B0: alloc_perm (db.c:3319)
==16614== by 0x42C635: load_rooms (db.c:1280)
==16614== by 0x42DACD: boot_db (db.c:437)
==16614== by 0x427CEF: main (comm.c:445)
==16614==
==16614== 131,072 bytes in 1 blocks are possibly lost in loss record 10 of 20
==16614== at 0x4C272B8: calloc (vg_replace_malloc.c:566)
==16614== by 0x4299B0: alloc_perm (db.c:3319)
==16614== by 0x42C72A: load_rooms (db.c:1319)
==16614== by 0x42DACD: boot_db (db.c:437)
==16614== by 0x427CEF: main (comm.c:445)
==16614==
==16614== 131,072 bytes in 1 blocks are possibly lost in loss record 11 of 20
==16614== at 0x4C272B8: calloc (vg_replace_malloc.c:566)
==16614== by 0x4299B0: alloc_perm (db.c:3319)
==16614== by 0x44FB5E: new_obj (recycle.c:224)
==16614== by 0x42A753: create_object (db.c:2455)
==16614== by 0x42BA65: reset_room (db.c:1879)
==16614== by 0x42BEE7: reset_area (db.c:2111)
==16614== by 0x42BF54: area_update (db.c:1704)
==16614== by 0x42DB99: boot_db (db.c:469)
==16614== by 0x427CEF: main (comm.c:445)
==16614==
==16614== 131,072 bytes in 1 blocks are possibly lost in loss record 12 of 20
==16614== at 0x4C272B8: calloc (vg_replace_malloc.c:566)
==16614== by 0x4299B0: alloc_perm (db.c:3319)
==16614== by 0x44FB5E: new_obj (recycle.c:224)
==16614== by 0x42A753: create_object (db.c:2455)
==16614== by 0x42BD18: reset_room (db.c:2017)
==16614== by 0x42BEE7: reset_area (db.c:2111)
==16614== by 0x42BF54: area_update (db.c:1704)
==16614== by 0x42DB99: boot_db (db.c:469)
==16614== by 0x427CEF: main (comm.c:445)
==16614==
==16614== 131,072 bytes in 1 blocks are possibly lost in loss record 13 of 20
==16614== at 0x4C272B8: calloc (vg_replace_malloc.c:566)
==16614== by 0x4299B0: alloc_perm (db.c:3319)
==16614== by 0x429A5D: alloc_mem (db.c:3239)
==16614== by 0x429AC5: str_dup (db.c:3349)
==16614== by 0x429ED7: fread_string (db.c:3038)
==16614== by 0x424132: load_board (board.c:372)
==16614== by 0x42420C: load_boards (board.c:417)
==16614== by 0x42DB9E: boot_db (db.c:470)
==16614== by 0x427CEF: main (comm.c:445)
==16614==
==16614== 262,144 bytes in 2 blocks are still reachable in loss record 14 of 20
==16614== at 0x4C272B8: calloc (vg_replace_malloc.c:566)
==16614== by 0x4299B0: alloc_perm (db.c:3319)
==16614== by 0x42E78D: load_objects (db2.c:430)
==16614== by 0x42DA89: boot_db (db.c:433)
==16614== by 0x427CEF: main (comm.c:445)
==16614==
==16614== 262,144 bytes in 2 blocks are still reachable in loss record 15 of 20
==16614== at 0x4C272B8: calloc (vg_replace_malloc.c:566)
==16614== by 0x4299B0: alloc_perm (db.c:3319)
==16614== by 0x44FB5E: new_obj (recycle.c:224)
==16614== by 0x42A753: create_object (db.c:2455)
==16614== by 0x42BD89: reset_room (db.c:2039)
==16614== by 0x42BEE7: reset_area (db.c:2111)
==16614== by 0x42BF54: area_update (db.c:1704)
==16614== by 0x42DB99: boot_db (db.c:469)
==16614== by 0x427CEF: main (comm.c:445)
==16614==
==16614== 393,216 bytes in 3 blocks are still reachable in loss record 16 of 20
==16614== at 0x4C272B8: calloc (vg_replace_malloc.c:566)
==16614== by 0x4299B0: alloc_perm (db.c:3319)
==16614== by 0x42C4A3: load_rooms (db.c:1221)
==16614== by 0x42DACD: boot_db (db.c:437)
==16614== by 0x427CEF: main (comm.c:445)
==16614==
==16614== 393,216 bytes in 3 blocks are still reachable in loss record 17 of 20
==16614== at 0x4C272B8: calloc (vg_replace_malloc.c:566)
==16614== by 0x4299B0: alloc_perm (db.c:3319)
==16614== by 0x42C635: load_rooms (db.c:1280)
==16614== by 0x42DACD: boot_db (db.c:437)
==16614== by 0x427CEF: main (comm.c:445)
==16614==
==16614== 524,288 bytes in 4 blocks are possibly lost in loss record 18 of 20
==16614== at 0x4C272B8: calloc (vg_replace_malloc.c:566)
==16614== by 0x4299B0: alloc_perm (db.c:3319)
==16614== by 0x44FB5E: new_obj (recycle.c:224)
==16614== by 0x42A753: create_object (db.c:2455)
==16614== by 0x42BD89: reset_room (db.c:2039)
==16614== by 0x42BEE7: reset_area (db.c:2111)
==16614== by 0x42BF54: area_update (db.c:1704)
==16614== by 0x42DB99: boot_db (db.c:469)
==16614== by 0x427CEF: main (comm.c:445)
==16614==
==16614== 524,288 bytes in 4 blocks are possibly lost in loss record 19 of 20
==16614== at 0x4C272B8: calloc (vg_replace_malloc.c:566)
==16614== by 0x4299B0: alloc_perm (db.c:3319)
==16614== by 0x44FA32: new_char (recycle.c:279)
==16614== by 0x42AE8C: create_mobile (db.c:2134)
==16614== by 0x42B8EC: reset_room (db.c:1826)
==16614== by 0x42BEE7: reset_area (db.c:2111)
==16614== by 0x42BF54: area_update (db.c:1704)
==16614== by 0x42DB99: boot_db (db.c:469)
==16614== by 0x427CEF: main (comm.c:445)
==16614==
==16614== 4,413,120 bytes in 1 blocks are still reachable in loss record 20 of 20
==16614== at 0x4C272B8: calloc (vg_replace_malloc.c:566)
==16614== by 0x42D5E0: boot_db (db.c:271)
==16614== by 0x427CEF: main (comm.c:445)
==16614==
==16614== LEAK SUMMARY:
==16614== definitely lost: 0 bytes in 0 blocks
==16614== indirectly lost: 0 bytes in 0 blocks
==16614== possibly lost: 1,966,080 bytes in 15 blocks
==16614== still reachable: 6,249,264 bytes in 17 blocks
==16614== suppressed: 0 bytes in 0 blocks
==16614==
==16614== ERROR SUMMARY: 12 errors from 12 contexts (suppressed: 4 from 4)
==16614==
==16614== 1 errors in context 1 of 12:
==16614== Invalid read of size 8
==16614== at 0x46615F: p_act_trigger (mob_prog.c:2184)
==16614== by 0x425933: act_new (comm.c:2618)
==16614== by 0x458FCC: spec_cast_adept (special.c:559)
==16614== by 0x45A40C: mobile_update (update.c:448)
==16614== by 0x45B5CB: update_handler (update.c:1248)
==16614== by 0x427804: game_loop_unix (comm.c:950)
==16614== by 0x4279E1: segv_handle (comm.c:553)
==16614== by 0x50981DF: ??? (in /lib/x86_64-linux-gnu/libc-2.13.so)
==16614== by 0x46615E: p_act_trigger (mob_prog.c:2184)
==16614== by 0x425933: act_new (comm.c:2618)
==16614== Address 0x18 is not stack'd, malloc'd or (recently) free'd
==16614==
==16614==
==16614== 1 errors in context 2 of 12:
==16614== Invalid read of size 8
==16614== at 0x46615F: p_act_trigger (mob_prog.c:2184)
==16614== by 0x425933: act_new (comm.c:2618)
==16614== by 0x4590C8: spec_cast_adept (special.c:579)
==16614== by 0x45A40C: mobile_update (update.c:448)
==16614== by 0x45B5CB: update_handler (update.c:1248)
==16614== by 0x427804: game_loop_unix (comm.c:950)
==16614== by 0x427D16: main (comm.c:463)
==16614== Address 0x18 is not stack'd, malloc'd or (recently) free'd
==16614==
==16614==
==16614== 1 errors in context 3 of 12:
==16614== Conditional jump or move depends on uninitialised value(s)
==16614== at 0x44F86B: free_affect (recycle.c:207)
==16614== by 0x43E25A: affect_remove (handler.c:1356)
==16614== by 0x4503F2: free_char (recycle.c:337)
==16614== by 0x43EAAE: extract_char (handler.c:2195)
==16614== by 0x404835: do_quit (act_comm.c:2214)
==16614== by 0x442BE0: interpret (interp.c:688)
==16614== by 0x421AD1: substitute_alias (alias.c:67)
==16614== by 0x4277D7: game_loop_unix (comm.c:934)
==16614== by 0x427D16: main (comm.c:463)
==16614== Uninitialised value was created by a stack allocation
==16614== at 0x481E5F: do_spellup (spellup.c:56)
==16614==
–16614–
–16614– used_suppression: 4 dl-hack3-cond-1
==16614==
==16614== ERROR SUMMARY: 12 errors from 12 contexts (suppressed: 4 from 4)
Segmentation fault
koqlb@mud:~/sv3b/area$


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:
/** Function: do_punload
* Descr : Returns a player, previously 'ploaded' back to the void from
* whence they came. This does not work if the player is actually
* connected.
* Returns : (void)
* Syntax : punload (who)
* Written : v1.0 12/97
* Author : Gary McNickle <gary@dharvest.com>
*/
void do_punload( CHAR_DATA *ch, char *argument )
{
CHAR_DATA *victim;
char who[MAX_INPUT_LENGTH];
char buf[MAX_STRING_LENGTH];
argument = one_argument(argument, who);

if ( ( victim = get_char_world( ch, who ) ) == NULL )
{
send_to_char( "They aren't here.\n\r", ch );
return;
}

/** Person is legitametly logged on… was not ploaded.
*/
if (victim->desc != NULL)
{
send_to_char("I dont think that would be a good idea…\n\r", ch);
return;
}

if (victim->was_in_room != NULL)
{
char_to_room(victim, victim->was_in_room);
if (victim->pet != NULL)
char_to_room(victim->pet, victim->was_in_room);
}

act("$n puts $N back in the filing cabinet.", ch, NULL, victim, TO_ROOM);
sprintf(buf, "You put %s back in the filing cabinet.\n\r", victim->name);
send_to_char(buf, ch);

save_char_obj(victim); /*
save_pinfo (victim); * Changed from do_quit function call –Koqlb
extract_char (victim, TRUE); */


}


I also just realized this function has no return at the end, which I will fix.

Here's my validate command:
/* Player validation command for new player
* restrictions. Allows players to use certain channels,
* set PK, and do other things on the MUD.
* –Koqlb
* Originally created 10/29/2014 for Subversive Visions.
*/
void do_pvalidate (CHAR_DATA * ch, char *argument)
{
char arg[MAX_INPUT_LENGTH];
char buf[MAX_STRING_LENGTH];
char buf2[MAX_STRING_LENGTH];
CHAR_DATA *victim;

one_argument (argument, arg);

if (arg[0] == '\0')
{
send_to_char ("Validate who?", ch);
return;
}

if ((victim = get_char_world (ch, arg)) == NULL)
{
send_to_char ("I don't see that player.\n\r", ch);
return;
}

if (get_trust (victim) >= get_trust (ch))
{
send_to_char ("You can't do that.\n\r", ch);
return;
}

if IS_SET (victim->act,PLR_VALIDATED)
{
send_to_char ("{WThey have already been {Cvalidated{W!{x\n\r", ch);
return;
}
else
{
SET_BIT (victim->act, PLR_VALIDATED);
send_to_char ("{WYou have been {YVALIDATED{W!!!{x\n\r",victim);
send_to_char ("{WYou may now set {RPK{W, use public channels,\n\r",victim);
send_to_char ("{Wjoin guilds, write notes, and more!\n\r", victim);
send_to_char("Validating player. OK!\n\r",ch);
sprintf (buf2, "$N has validated %s.", victim->name);
wiznet (buf, ch, NULL, WIZ_PENALTIES, WIZ_SECURE, 0);
/* Level 2? If so, save the character file*/
if (victim->level >= 2)
{
save_char_obj(victim);
}
}

return;
}

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.
20 Jan, 2015, koqlb wrote in the 2nd comment:
Votes: 0
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:
Votes: 0
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:
Votes: 0
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:
Votes: 0
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:
Votes: 0
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;
}
}
}


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:
Votes: 0
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:
Votes: 0
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.
22 Jan, 2015, SlySven wrote in the 9th comment:
Votes: 0
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:
Votes: 0
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:
Votes: 0
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.
22 Jan, 2015, Tijer wrote in the 12th comment:
Votes: 0
Worked out the fix you need to put the following line in
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:
Votes: 0
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:
Votes: 0
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:
Votes: 0
@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:
Votes: 0
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:
Votes: 0
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:
Votes: 0
depends how your connected states work.. usually con_playing is the highest connected state….. well is on muds ive worked on anyways…
0.0/18