So this is mostly stock Quickmud. I've only changed code to test the player run channels snippet that Midboss made for rom.
It happens when I'm doing repeated commands. ie ".join babble" (joins the babble channel). This is using the same command more than once a few times. What I got from gdb though is this.

Program received signal SIGSEGV, Segmentation fault.
song_update () at music.c:103
103	        if (obj->item_type != ITEM_JUKEBOX || obj->value[1] < 0)

Error summary from valgrind shows

==29324== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 0 from 0)
==29324== 
==29324== 1 errors in context 1 of 7:
==29324== Invalid read of size 2
==29324==    at 0x465CCB: song_update (music.c:103)
==29324==    by 0x4858C3: update_handler (update.c:1169)
==29324==    by 0x42F44A: game_loop_unix (comm.c:861)
==29324==    by 0x42F789: main (comm.c:459)
==29324==  Address 0x6b6cd9 is not stack'd, malloc'd or (recently) free'd
==29324== 
==29324== 
==29324== 1 errors in context 2 of 7:
==29324== Syscall param socketcall.accept(addrlen_out) points to uninitialised byte(s)
==29324==    at 0x516BC50: __accept_nocancel (syscall-template.S:81)
==29324==    by 0x42E749: init_descriptor (comm.c:949)
==29324==    by 0x42F1A8: game_loop_unix (comm.c:775)
==29324==    by 0x42F789: main (comm.c:459)
==29324==  Address 0xffeffe9ac is on thread 1's stack
==29324==  Uninitialised value was created by a stack allocation
==29324==    at 0x42E70E: init_descriptor (comm.c:940)
==29324== 
==29324== 
==29324== 1 errors in context 3 of 7:
==29324== Syscall param socketcall.accept(addrlen_in) points to uninitialised byte(s)
==29324==    at 0x516BC50: __accept_nocancel (syscall-template.S:81)
==29324==    by 0x42E749: init_descriptor (comm.c:949)
==29324==    by 0x42F1A8: game_loop_unix (comm.c:775)
==29324==    by 0x42F789: main (comm.c:459)
==29324==  Address 0xffeffe9ac is on thread 1's stack
==29324==  Uninitialised value was created by a stack allocation
==29324==    at 0x42E70E: init_descriptor (comm.c:940)
==29324== 
==29324== 
==29324== 1 errors in context 4 of 7:
==29324== Syscall param socketcall.getsockname(namelen_out) points to uninitialised byte(s)
==29324==    at 0x516BD67: getsockname (syscall-template.S:81)
==29324==    by 0x42E738: init_descriptor (comm.c:948)
==29324==    by 0x42F1A8: game_loop_unix (comm.c:775)
==29324==    by 0x42F789: main (comm.c:459)
==29324==  Address 0xffeffe9ac is on thread 1's stack
==29324==  Uninitialised value was created by a stack allocation
==29324==    at 0x42E70E: init_descriptor (comm.c:940)
==29324== 
==29324== 
==29324== 1 errors in context 5 of 7:
==29324== Syscall param socketcall.getsockname(namelen_in) points to uninitialised byte(s)
==29324==    at 0x516BD67: getsockname (syscall-template.S:81)
==29324==    by 0x42E738: init_descriptor (comm.c:948)
==29324==    by 0x42F1A8: game_loop_unix (comm.c:775)
==29324==    by 0x42F789: main (comm.c:459)
==29324==  Address 0xffeffe9ac is on thread 1's stack
==29324==  Uninitialised value was created by a stack allocation
==29324==    at 0x42E70E: init_descriptor (comm.c:940)
==29324== 
==29324== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

New to debugging and C green so please bare with me. I don't know the programs that well either. Used gdb rom for the first code. valgrind -v –leak-check=yes –show-reachable=yes –track-origins=yes for the second.

Any thoughts? I could remove the channels snippet and it would go away since I haven't come across this before. It would be good to know how to use this to figure out where and why though.

Line 103 in music.c, check if obj (is not NULL).

I'm not familiar with the code concerned but even if obj is not NULL and does point to something valid, are you guaranteed that there is at least 2 members in the value array { value[0] AND value[1] }?

Finally found it's something quirky with the channel script in channels.c. It's in the way it's reading and writing to the players pfile. In one instance I was able to save my pfile where it had written over where my prompt is stored. So it's going to have to be rewritten to work. It bugged out on me with a new player with no save file yet. So advanced him and saved later and the joined channel was in there correctly this time. I'm just not sure how this code ended up affecting other code within the mud such as in music.c

Sounds like a memory corruption issue. I'd run valgrind against it. Odds are good it's still broken and will break again in the future.

-dentin

Alter Aeon MUD
http://www.alteraeon.com

Just a quick note on checking against NULL in ROM. It might not have much to do with your situation but it may help in debugging. I've found that checking against NULL is not always enough since ROM's memory system doesn't free objects, it just puts them in a recycled list. So even if the object was recycled (by a call to extract_obj() most likely), it's not NULL. If your version of new_obj() and free_obj() both VALIDATE() and INVALIDATE() the obj, then you can check if the object is NULL and also check if obj->valid. If it isn't valid, then you at least know you're looking at a recycled object, whose fields may have been freed, nullified, etc, so it's not safe to dereference the object in that case. Don't know if that helps with anything, just something that's helped me a lot with debugging, especially in functions that call extract_obj() but later may still reference the object, so you can first check if it's still valid before continuing to use the object's fields.