On Thu, 18 Dec 1997, Chuck Carson wrote:
> Can anyone help me figure this out? The mud crashes every time a mob hits a
> death trap (now that I think about it, I believe only mobs with one of the
> below bits set, AGGR's). Here is the code causing the crash. This is stock
> code except for the intial if statement, I have added the 128 bit vector
> code and must test each flag individually (instead of MOB_FLAGGED(ch, XXXX |
> XXXXXX)). This however is unrelated. The mud has no problem getting by this
> line. When it enters the for loop, crashola. This code, from the binary
> level, should be no different than the stock code. This is driving me crazy.
>
> /* Aggressive Mobs */
> if ((MOB_FLAGGED(ch, MOB_AGGRESSIVE)) || (MOB_FLAGGED(ch,
> MOB_AGGR_TO_ALIGN)))
> found = FALSE;
> PROBLEM:for (vict = world[ch->in_room].people ; vict && !found; vict =
> vict_next) {
> if (IS_NPC(vict) || !CAN_SEE(ch, vict) || PRF_FLAGGED(vict,
> PRF_NOHASSLE))
> continue;
> if (MOB_FLAGGED(ch, MOB_WIMPY) && AWAKE(vict))
> continue;
> if (!MOB_FLAGGED(ch, MOB_AGGR_TO_ALIGN) ||
> (MOB_FLAGGED(ch, MOB_AGGR_EVIL) && IS_EVIL(vict)) ||
> (MOB_FLAGGED(ch, MOB_AGGR_NEUTRAL) && IS_NEUTRAL(vict)) ||
> (MOB_FLAGGED(ch, MOB_AGGR_GOOD) && IS_GOOD(vict))) {
> hit(ch, vict, TYPE_UNDEFINED);
> found = TRUE;
> vict_next = vict->next_in_room;
Here is your problem. You assign vict_next the wrong place. Do it as the
first thing in the for() statement. As I wrote last time:
for (vict=world[ch->in_room].people; vict && !found; vict = vict_next) {
vict_next = vict->next_in_room;
// Then the rest...
}
> }
> }
> }
>
> Here is the useless gdb output:
> /home/chuck/circle/src ===>gdb ../bin/circle ../lib/core
> GDB is free software and you are welcome to distribute copies of it
> under certain conditions; type "show copying" to see the conditions.
> There is absolutely no warranty for GDB; type "show warranty" for details.
> GDB 4.16 (i486-slackware-linux), Copyright 1996 Free Software Foundation,
> Inc...
> Core was generated by `bin/circle 9999'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /lib/libc.so.5...done.
> Reading symbols from /lib/ld-linux.so.1...done.
> #0 0x8073e5a in mobile_activity () at mobact.c:95
> Source file is more recent than executable.
> 95 for (vict = world[ch->in_room].people ; vict && !found; vict =
> vict_next) {
> (gdb) back
> #0 0x8073e5a in mobile_activity () at mobact.c:95
> #1 0x8049e98 in heartbeat (pulse=400) at comm.c:699
> #2 0x8049e12 in game_loop (mother_desc=3) at comm.c:674
> #3 0x804949e in init_game (port=9999) at comm.c:267
> #4 0x8049430 in main (argc=2, argv=0xbffffb84) at comm.c:237
> #5 0x804915e in _start ()
> (gdb) quit
backtrace isn't enough debugging. You got to work with it a little.
Try stuff like 'print *vict' and 'print *vict_next' ..
>
> I am sure it is a null pointer crash bug but why? Why is this error not
> occuring in the stock version of the code. Can my problem lie elsewhere?
vict to extracted before you assigned vict_next. Thats why you get a null
pointer. And else you have been lucky if it didn't crash in stock :)
Personally I think all those "for()"'s should be checked in stock circle.
> This is a rather top level function so this leaves me empty handed. What
> really irkes the shit out of me as it only happens in death trap rooms. I
> could understand this crash if it occured for any mob in any room, but this
> crash bug eludes me. Just curious, how many people use the 128 bit vector
> code without problems. I tried this code 1 1/2 years ago in a heavily
> altered bpl11 and eventually gave up and am now trying it in a stock bpl 12.
Been a while since I made the 128bit code. And lost my MUD site before I
could use it in my own MUD fully. Since then I have been coding a little
for StrangeMUD. They ran out of MOB flags. But this time I took my time
and looked into bitfields. Can't say if its more work than the 128 bit,
but in the long run I think I like bitfields better.
> (although I have been away from circle for a year working on rom and am a
> bit fuzzy) There are no players in the room when this for loop executes so
> why is it executing the loop? I am he only char logged into the game when
> this occurs and it also occurs if no one has logged in.
Doesn't really matter.. Problem is still that you assign vict_next after
vict got extracted, which means vict->next_in_room can point anywhere and
don't have to be a null pointer (which will make the for() continue). If
so then the new vict pointer, points to the memory space which are 99%
sure not a char_data. == crash crash
> Thanks in adavance for any help,
Hope it helps,
Erik Niese-Petersen
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/08/00 PST