Mike Redick wrote:
>
> Ok... wrote a little code so that room spec procs could be called randomly
> like mob spec procs. It works perfectly on my end (win95, MSVC++ 6.0
> compiler) but when the imp of my mud tries to put it in it crashes, he's
> using some version of Linux I think... not sure what compiler, probably gcc
> or somethin.
>
> void obj_activity( void )
> {
> register struct obj_data *obj, *next_obj;
>
> for (obj = object_list; obj; obj = next_obj)
> {
> next_obj = obj->next;
>
> if( obj_index[ GET_OBJ_RNUM( obj )].func != NULL )
> (obj_index[GET_OBJ_RNUM(obj)].func) (NULL, obj, 0, "");//crashes here
> }
> }
>
> This is the information he sent me about the crash:
>
> This is what the gdb spits out from the core dump after the
> obj activity stuff.
>
> line 1013 in comm.c is the obj_activity();
>
> #0 0xa0d in ?? ()
> (gdb) bt
> #0 0xa0d in ?? ()
> #1 0x80a32bc in heartbeat (pulse=20) at comm.c:1013
> #2 0x80a2da3 in game_loop (mother_desc=4) at comm.c:843
> #3 0x80a21fd in init_game (port=9999) at comm.c:409
> #4 0x80a2175 in main (argc=2, argv=0xbffff9c4) at comm.c:354
> (gdb)
>
> So anyone know why this would happen? Some wierd portability issue or
> somethin?
This looks like some other seg fault in the code that is overwriting the
location of the new function, hence when the program tries to call the
function it is sent off to some seemingly random area of memory and
tries to run it (and crashes doing so).
In other words, your imp has a seg fault that was sitting around quietly
not doing much of anything (or maybe it is responsible for some other
bug which has been plauging the MUD) until this new code went in, then
the seg fault reared its ugly head.
It could be a number of other things, but that's what pops out at me as
being the most likely cause.
Regards, Peter
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/11/01 PDT