19 Apr, 2011, Rojan QDel wrote in the 1st comment:
Votes: 0
So I've had this bug for a while that I've been completely unable to fix or diagnose, mostly because I'm not sure what the point of the original code is…

Here is the code:
if ( !xIS_SET( ch->act, ACT_RUNNING ) && ch->spec_fun )
if ( (*ch->spec_fun) (ch) ) continue;
if ( char_died(ch) ) continue;

On line 3 with if ( (*ch->spec_fun) (ch) ) continue; it gives me a nice fat SIGSEGV
When I run it in gdb, I print ch, ch->spec_fun, and *ch->spec_fun and they all look fine
If I print (*ch->spec_fun) (ch) then GDB gives me a SIGSEGV….

I'm not sure what the point of this code is, it exists in SWRFUSS update.c:828 as well, and seems to date back quite a while according to those 2002 mailing list submission asking for help with the same issue in ROM: http://www.mail-archive.com/rom@rom.org/...

So, if anyone can shed some light as to what this line's purpose is and what the fix might be, I'd appreciate it.
19 Apr, 2011, Kaz wrote in the 2nd comment:
Votes: 0
spec_fun is a function pointer. Here, it is being called only if it is not NULL, and the character in question is not "running".

Therefore, if spec_fun it is not initialised to either NULL or a real function, then calling it will likely crash. Finding the source of this error will be fun.
19 Apr, 2011, Rojan QDel wrote in the 3rd comment:
Votes: 0
I mean, I understand what that code itself does. I just have no clue what its purpose is on a higher level in the MUD… It should be executing the special function, in which case commenting out could be very bad :)
19 Apr, 2011, Kaz wrote in the 4th comment:
Votes: 0
I would recommend the time-tested technique of 'printf debugging'. You know it's going to crash there, so dump everything you know about the mob that's triggering the crash just before it would happen. That way, you'll know which mob it is and be able to see if, for example, it has a weird spec_fun entry or something.
19 Apr, 2011, Rojan QDel wrote in the 5th comment:
Votes: 0
Fixed, apparently specfun wasn't actually being assigned in mset, so it would break if you mset a spec_fun on a mob but when it booted up with the spec_fun already set it worked fine.