29 Oct, 2008, Igabod wrote in the 1st comment:
Votes: 0
alright, i'm toolin around with keggermud (quickmud deriv) and i attempted to make levelling give you a different number of trains based on your int stat, that didn't work so i reset everything back to the way it was before except i set it so you get 2 trains instead of 1 which shouldn't cause any problems but now whenever any character levels my mud crashes. i get this line in cygwin.

Wed Oct 29 01:02:02 2008 :: Newtest@Comcrap has connected.
23 [main] rom 5596 _cygtls::handle_exceptions: Error while dumping state (p
robably corrupted stack)
Segmentation fault (core dumped)


the advance_level function is below

void advance_level (CHAR_DATA * ch, bool hide)
{
char buf[MAX_STRING_LENGTH];
int add_hp;
int add_mana;
int add_move;
int add_prac;

ch->pcdata->last_level =
(ch->played + (int) (current_time - ch->logon)) / 3600;

sprintf (buf, "the %s",
title_table[ch->class][ch->level][ch->sex ==
SEX_FEMALE ? 1 : 0]);
set_title (ch, buf);

add_hp =
con_app[get_curr_stat (ch, STAT_CON)].hitp +
number_range (class_table[ch->class].hp_min,
class_table[ch->class].hp_max);
add_mana = number_range (2, (2 * get_curr_stat (ch, STAT_INT)
+ get_curr_stat (ch, STAT_WIS)) / 5);
if (!class_table[ch->class].fMana)
add_mana /= 2;
add_move = number_range (1, (get_curr_stat (ch, STAT_CON)
+ get_curr_stat (ch, STAT_DEX)) / 6);
add_prac = wis_app[get_curr_stat (ch, STAT_WIS)].practice;

add_hp = add_hp * 10 / 11;
add_mana = add_mana * 10 / 11;
add_move = add_move * 10 / 11;

add_hp = UMAX (2, add_hp);
add_mana = UMAX (2, add_mana);
add_move = UMAX (6, add_move);

ch->max_hit += 1 + add_hp;
ch->max_mana += 1 + add_mana;
ch->max_move += 1 + add_move;
ch->practice += 1 + add_prac;
ch->train += 2;

ch->pcdata->perm_hit += 1 + add_hp;
ch->pcdata->perm_mana += 1 + add_mana;
ch->pcdata->perm_move += 1 + add_move;

if (!hide)
{
sprintf (buf,
"You gain %d hit point%s, %d mana, %d move, and %d practice%s.\n\r",
add_hp+1, add_hp == 1 ? "" : "s", add_mana+1, add_move+1,
add_prac+1, add_prac == 1 ? "" : "s");
send_to_char (buf, ch);
}
return;
}


please help
29 Oct, 2008, quixadhal wrote in the 2nd comment:
Votes: 0
I know cygwin isn't the most friendly environment to work in, but if they have ported gdb to it, it would be MUCH easier to pin down the error if you could run the driver with gdb and then post a backtrace (bt command…. or maybe it's tb). That should pin down the line that actually caused the exception.
29 Oct, 2008, Igabod wrote in the 3rd comment:
Votes: 0
cygwin does have gdb but i have no clue how to use it. i usually just figure out where the bug is myself and i'm sure this one is in advance_level cause it only happens as soon as the character gains a level. i've recreated this many many times and it's always the same. i just don't know whats wrong with this code. my best guess is it's in this bit of code.

sprintf (buf,
"You gain %d hit point%s, %d mana, %d move, and %d practice%s.\n\r",
add_hp+1, add_hp == 1 ? "" : "s", add_mana+1, add_move+1,
add_prac+1, add_prac == 1 ? "" : "s");
send_to_char (buf, ch);
}

cause that is the only thing i've changed from the original but i haven't tested this theory yet, gotta wait till i get off work.
29 Oct, 2008, quixadhal wrote in the 4th comment:
Votes: 0
The thing is, it might be crashing elsewhere as a result of something this routine changes. Looking at the stack trace would tell you exactly what line is crashing without spending hours trying to guess.

The only guess I could give for that is that it could be an order of operations issue. try putting parens around the (add_hp == 1 ? "" : "s") expressions.

gdb isn't hard to learn, and is WELL worth the time. You don't need to be an expert with it, most of the time just running your code in it and looking at the backtrace tells you most of what you need to know.
29 Oct, 2008, Igabod wrote in the 5th comment:
Votes: 0
i know a little bit about gdb but what little i do know is that you need to have the mud running as well as have gdb active and then crash it. problem there is that i'm running it through cygwin using the ../src/rom 4444 method and in cygwin i can't do anything within the shell as long as the exe file is running. is there a guide to using gdb for muds available anywhere? just thought i'd ask that in case someone also tells me how to run the mud and be able to use cygwin at the same time *just a side note, the ./startup & 4444 command doesn't work in cygwin which is why i'm using the exe file.*
29 Oct, 2008, quixadhal wrote in the 6th comment:
Votes: 0
just invoke it as gdb ../src/rom, and then from the debugger prompt, do "run 4444"

That lets gdb run the process but intercept all signals, so when it crashes, it can point you to the problem.

You will also need to compile and link it with -g, if you haven't already. Just add those to your makefile, usually in CFLAGS and LFLAGS, although the names vary. That adds debugging symbol information so it can display everything for you. If your makefile has a -s flag on the part that links the executable, remove that (-s strips out the debugging symbols).

I don't know of any good gdb references off-hand, I leared it years ago, the hard way. :)
29 Oct, 2008, Igabod wrote in the 7th comment:
Votes: 0
here's my makefile
# $Id $

# Makefile for Rom24. Works fine on my Debian system.
# You may need to use 'gmake' on BSD systems.

CC = gcc
RM = rm
EXE = rom
PROF = -O -ggdb
CYGWIN = -DCYGWIN

# Use these two lines to use crypt(), ie on Linux systems.
# C_FLAGS = $(PROF) -Wall
# L_FLAGS = $(PROF) -lcrypt

# Uncomment these two lines to use plaintext passwords.
# This is how you fix the 'crypt' linking errors!
C_FLAGS = -Wall $(PROF) -DNOCRYPT -DQMFIXES
L_FLAGS = $(PROF)

# Source Files
SRC_FILES := $(wildcard *.c)

# Object Files
OBJ_DIR = obj
OBJ_FILES := $(patsubst %.c,$(OBJ_DIR)/%.o,$(SRC_FILES))

rom: $(OBJ_FILES)
$(RM) -f $(EXE)
$(CC) $(L_FLAGS) -o $(EXE) $(OBJ_FILES)

$(OBJ_DIR)/%.o: %.c
$(CC) $(C_FLAGS) -c -o $@ $<

clean:
$(RM) -f $(OBJ_FILES) $(EXE) *~ *.bak *.orig *.rej
29 Oct, 2008, Igabod wrote in the 8th comment:
Votes: 0
i did what you said and got the following error message in gdb

Wed Oct 29 05:42:27 2008 :: Loading Newtest.
Wed Oct 29 05:42:30 2008 :: Newtest@Comcrap has connected.
Wed Oct 29 05:44:01 2008 :: Newtest gained level 4!

Program received signal SIGSEGV, Segmentation fault.
room_is_dark (pRoomIndex=0x0) at handler.c:2540
2540 if (pRoomIndex->light > 0)
(gdb)


here's that line and the ones surrounding it.

/*
* True if room is dark.
*/
bool room_is_dark (ROOM_INDEX_DATA * pRoomIndex)
{
if (pRoomIndex->light > 0)<<<<<——-this is the line it points to.
return FALSE;

if (IS_SET (pRoomIndex->room_flags, ROOM_DARK))
return TRUE;

if (pRoomIndex->sector_type == SECT_INSIDE
|| pRoomIndex->sector_type == SECT_CITY) return FALSE;

if (weather_info.sunlight == SUN_SET || weather_info.sunlight == SUN_DARK)
return TRUE;

return FALSE;
}


my question is why is this crashing the mud every time somebody levels?
29 Oct, 2008, quixadhal wrote in the 9th comment:
Votes: 0
That, I don't know… however if that's where it is crashing, pRoomIndex is probably either NULL or corrupted.

If the player is in an odd environment when they level (IE: they attempt to move to a non-existent room), or if something else overwrites and trashes the pointer, and the crash just doesn't happen until it's accessed….

Try either the tb or bt command (I don't recall which one it is… it should list the calling stack, from the point it crashed backwards up the tree. That'll tell you what called room_is_dark().

To try to investigate, you can use the command print to look at the values of variables or expressions (print pRoomIndex, and if not NULL you can print *pRoomIndex to try and examine the structure). You also use the command "up" to move up the call stack.

For example, if you type "list" at the prompt there, you'd see the code around the line that crashed. If you type "up" and then do another "list", you'll see the code around the point that routine was called.

Looking at what got passed in to room_is_dark is probalby a good place to start.
29 Oct, 2008, Igabod wrote in the 10th comment:
Votes: 0
went up and typed list and got this
2636            return TRUE;
2637
2638 if (IS_AFFECTED (ch, AFF_BLIND))
2639 return FALSE;
2640
2641 if (room_is_dark (ch->in_room) && !IS_AFFECTED (ch, AFF_INFRARED))
2642 return FALSE;
2643
2644 if (IS_AFFECTED (victim, AFF_INVISIBLE)
2645 && !IS_AFFECTED (ch, AFF_DETECT_INVIS))
(gdb)

i don't see any problems with that either. so i type up and list
#2  0x00437562 in violence_update () at fight.c:102
102 if (can_see (victim, ch))
(gdb) list
97 chance = get_skill (ch, gsn_sword) / 15;

98
99 /*
100 * Penalty if the opponent can see.
101 */
102 if (can_see (victim, ch))
103 chance = chance * 3 / 5;
104
105 for (vch = ch->in_room->people; vch != N
ULL;
106 vch = vch->next_in_room)

this MAY be causing the problem, i installed a snippet to make weapons more diversified and was kinda unsure about where to put this bit *if this is the part im thinking of.*

btw, when i type bt i get this message
#0  room_is_dark (pRoomIndex=0x0) at handler.c:2540
#1 0x0044307d in can_see (ch=0x12f41b8, victim=0x1386404) at handler.c:2641
#2 0x00437562 in violence_update () at fight.c:102
#3 0x00478537 in update_handler () at update.c:1199
#4 0x0042c332 in game_loop_unix (control=5) at comm.c:844
#5 0x0042bdc8 in main (argc=2, argv=0x11a19a0) at comm.c:448
(gdb)


and tb gets me this
(gdb) tb
Note: breakpoint 1 also set at pc 0x44307d.
Breakpoint 2 at 0x44307d: file handler.c, line 2641.
29 Oct, 2008, David Haley wrote in the 11th comment:
Votes: 0
Your problem is that ch is in a NULL room. How that happened is unclear. You need to go over your changes and see what affects the character's room. Incidentally, it looks like this has nothing to do with leveling: do you mean that the problem occurs after leveling? It's extremely important to be precise, otherwise you'll be going after red herrings and waste a lot of time.
29 Oct, 2008, quixadhal wrote in the 12th comment:
Votes: 0
Yep, since ch and victim are both pointing to something, and ch->in_room is NULL, odds are that something, somewhere, has moved your character out of their current room and not put them back into another room. At that point, I'd probably print *ch to see if the rest of the values make sense, and then start putting in debug statements to try and figure out where your character's room got erased.

If it always happens when you level, and you're in the middle (or at the end) of some fight here, I'd probably poke around the routines that handle mob death. Perhaps something was supposed to set victim->in_room to NULL and instead set ch->in_room to NULL. Or maybe you passed ch instead of victim somewhere.

I hope this helps, we probably can't help you fix this particular problem, but I'm hoping we can help you figure out how to fix it.
30 Oct, 2008, Igabod wrote in the 13th comment:
Votes: 0
i solved it by commenting out the following lines.

# 102                                    if (can_see (victim, ch))
# 103 chance = chance * 3 / 5;


now it works fine. apparently it was crashing right before the character actually got the level but after the mob was killed. i'm not sure why but commenting out those lines fixed the problem. now i just gotta figure out how to make that part work without crashing.
30 Oct, 2008, David Haley wrote in the 14th comment:
Votes: 0
Of course, you haven't actually solved the problem, you've just made the symptom go away without addressing the root. What you've done is comparable to "curing" a skin disease by slicing off the skin on top… FWIW I highly recommend that you not consider that your code "works fine", and I would uncomment those lines since they're really not the ones responsible for your issue. You need to figure out why the character's room is being set to null – that is your issue.
30 Oct, 2008, Igabod wrote in the 15th comment:
Votes: 0
by works fine i mean it plays with no crashes, i know i haven't "fixed" anything at all, hence me saying "now i just gotta figure out how to make that part work without crashing". the thing is i don't know WHY it's setting the room to null. those two lines are the ones crashing the mud but it makes doesn't mention anything about setting the room to null. everywhere else that can_see is mentioned in the code works without crashing too so i don't know why this particular one does it. i was kinda hoping someone could give me some insight into how to figure this out. i have an idea for fixing this by looking at the other mentions of can_see. my idea is to change the if can_see part to this.
if (rch != NULL && can_see (victim, ch))


i may be completely wrong about the rch but i think thats refering to the room the character is in. not sure where that is defined and it's not in merc.h and i'm too lazy to look any further for it due to the large number of mentions of it in the code so i'm not changing anything yet. but if someone can tell me if i'm correct before i go home and actually dig around that would be great.

[edit to fix typos]
30 Oct, 2008, Davion wrote in the 16th comment:
Votes: 0
I think you may want that can_see call using rch in some way instead of victim, or ch.
30 Oct, 2008, Igabod wrote in the 17th comment:
Votes: 0
hmm… now that i think about what i just posted i don't think that'll fix anything… i'm really just confusing myself right now trying to figure out the cause of this whole thing. i'm gonna dig around and see where can_see is defined.

[edit to add this]
hmm, that didn't really help me at all… maybe i've been spending too much time on this and need to give my brain a rest and then come back to it tomorrow since my band-aid fix is doing fine. because of this one problem i've not gotten anything done since day before yesterday.
30 Oct, 2008, David Haley wrote in the 18th comment:
Votes: 0
There's some methodology to all of this. First, did it happen before you made your character leveling changes? If not, you can be fairly confident that whatever you did there is the culprit. If you were doing other things at the same time (a somewhat dangerous thing, for this reason) you need to look there as well. You know what variable is null that shouldn't be, so that gives you a start: in the relevant sections you changed, home in on anything having to do with the room. can_see is your symptom, not your cause, so you probably don't need to worry about it too much – as long as you are calling it with the right arguments. Don't change things just for the sake of changing things. Keep track of everything you do, or you might introduce new problems that will cause further confusion in the process, or worse yet, much later on. Version control is a great way to track your changes, but really even just fully copying your code at regular intervals is better than nothing.
31 Oct, 2008, Skol wrote in the 19th comment:
Votes: 0
Sounds like it's referring to the victim after the damage has been done, so the victim is dead and then not in a room (extracted) so the room is NULL (0x0 in the gdb backtrace). What I would do is put a check in the bool 'can_see' that if the victim's room , or the player's room doesn't exist, return FALSE.

ie.
if (victim->in_room == NULL || ch->in_room == NULL)
return FALSE;
31 Oct, 2008, Igabod wrote in the 20th comment:
Votes: 0
DavidHaley said:
There's some methodology to all of this. First, did it happen before you made your character leveling changes? If not, you can be fairly confident that whatever you did there is the culprit. If you were doing other things at the same time (a somewhat dangerous thing, for this reason) you need to look there as well. You know what variable is null that shouldn't be, so that gives you a start: in the relevant sections you changed, home in on anything having to do with the room. can_see is your symptom, not your cause, so you probably don't need to worry about it too much – as long as you are calling it with the right arguments. Don't change things just for the sake of changing things. Keep track of everything you do, or you might introduce new problems that will cause further confusion in the process, or worse yet, much later on. Version control is a great way to track your changes, but really even just fully copying your code at regular intervals is better than nothing.

some very good words of advice there, i am not really keeping any sort of organized changes list but thats cause this is never going to be played by anybody but me. i'm just using this for learning experience so i can make a good mud later on. i should get in the habit of being a little more organized now though. as to the topic of my crash bug, when i fiddled with the xp_compute function i had just finished installing a snippet i downloaded from here and hadn't fully tested. the snippet was to make weapons more diverse and the can_see part that is in question was a part of that snippet. it happens to be in the part that determines the special features of swords and i didn't test swords out at all. that happens to be the weapon type of the character i was using to test the exp changes with. so i'm pretty positive the culprit is in the can_see function. i'm about to test out the fix skol gave. it looks like it might just be the answer.

[edit to add]nope that didn't work. it crashed again.
0.0/92