28 Jan, 2011, Vfx23 wrote in the 1st comment:
Votes: 0
Ok, I fixed some of the issues in my last post, but now I still get these warnings. Im guessing thats what keeps crashing my mud so much for no reason. Everything is fine, and all of a sudden bam, crashes. Here are the warnings Im getting.


gcc -c -Wall -O -ggdb act_comm.c
act_comm.c: In function 'do_say':
act_comm.c:233: warning: unused variable 'buf'


act_info.c: In function 'do_who':
act_info.c:2617: warning: assignment discards qualifiers from pointer target type
act_info.c:2618: warning: assignment discards qualifiers from pointer target type
act_info.c:2624: warning: assignment discards qualifiers from pointer target type
act_info.c:2625: warning: assignment discards qualifiers from pointer target type
act_info.c: In function 'do_become':
act_info.c:4273: warning: unused variable 'class2'
act_info.c: In function 'do_score':
act_info.c:1562: warning: 'class2' may be used uninitialized in this function
act_info.c: In function 'do_who':
act_info.c:2450: warning: 'class2' may be used uninitialized in this function


act_wiz.c: In function 'do_relevel':
act_wiz.c:355: warning: unused variable 'buf'
act_wiz.c: In function 'do_sockets':
act_wiz.c:5060: warning: implicit declaration of function 'strftime'
act_wiz.c:5060: warning: incompatible implicit declaration of built-in function 'strftime'
act_wiz.c:5060: warning: implicit declaration of function 'localtime'
act_wiz.c:5060: warning: passing argument 4 of 'strftime' makes pointer from integer without a cast
act_wiz.c: In function 'do_otype':
act_wiz.c:6617: warning: comparison between pointer and integer
act_wiz.c:6631: warning: implicit declaration of function 'flag_value'
act_wiz.c: In function 'do_arealinks':
act_wiz.c:6300: warning: 'buffer' may be used uninitialized in this function

comm.c: In function 'init_descriptor':
comm.c:921: warning: pointer targets in passing argument 3 of 'getsockname' differ in signedness
comm.c:922: warning: pointer targets in passing argument 3 of 'accept' differ in signedness
comm.c:955: warning: pointer targets in passing argument 3 of 'getpeername' differ in signedness

db.c:3359:7: warning: extra tokens at end of #endif directive
gcc -c -Wall -O -ggdb db2.c
gcc -c -Wall -O -ggdb effects.c
gcc -c -Wall -O -ggdb fight.c
fight.c: In function 'damage':
fight.c:1598: warning: control reaches end of non-void function

magic.c: In function 'spell_chill_touch':
magic.c:1808: warning: 'paf_old.duration' is used uninitialized in this function
magic.c:1817: warning: 'paf_old.modifier' is used uninitialized in this function

olc.h:114: warning: 'struct flag_type' declared inside parameter list
olc.h:114: warning: its scope is only this definition or declaration, which is probably not what you want
olc.h:116: warning: 'struct flag_type' declared inside parameter list


Any help would be appreciated, either by email, msn (same as my email) on my mud, or here. Thanks to everyone who is helping me, I really appreciate it.
28 Jan, 2011, Runter wrote in the 2nd comment:
Votes: 0
These warnings probably represent some minor errors, but they're probably not what is crashing your game "for no reason." To find the answer to that problem I suggest you use a debugger such as gdb and figure out definitively what lines of code and the circumstances (and state of your program) at the moment it crashes. Nobody can do anything but guess until you do this, really.
28 Jan, 2011, Vfx23 wrote in the 3rd comment:
Votes: 0
Ive tried using gdb, but dont know how to use it. That's why Im looking to get a coder to try to help me fix this problem.
28 Jan, 2011, Kline wrote in the 4th comment:
Votes: 0
31 Jan, 2011, Vfx23 wrote in the 5th comment:
Votes: 0
thanks a lot for that guide. A person told me that when you attach gdb to the mud, the mud is supposed to freeze, if it doesnt, then you did something wrong. I have a couple of questions about gdb, and what I do to attach it (so you can tell me if thats the right way or not)

For the question. When it shell, frostmuds server disconnects you if you idle like 3 minutes in shell. So if you attach gdb, and you get disconnected, is gdb still active when you log back on, or do you have to attach it again? Another thing, after it crashed, how do I look in gdb at what the problem was?

Now for what I do to attach gdb, I think Im doing it right, correct me if I am doing it wrong please.

./startup (port) &

gdb ../startup/rom and the pid what it shows for startup

If thats right, why isnt the mud freezing like I was told it should?
31 Jan, 2011, Vfx23 wrote in the 6th comment:
Votes: 0
Ok, so I booted the mud in gdb now, using gdb ../src/rom then set args 8310 and then run

this is what I get


Err: obj a {bs{Dt{Wo{Dr{bm{X spear (23201) – 118, mob a {bs{Dt{Wo{Dr{bm {Dt{wi{Wt{wa{Dn{X (23201) – 87
Err: obj an {Dada{Wman{Dtine{X poleaxe (23202) – 100, mob a {Dt{wi{Wt{wa{Dn{X (23202) – 87
Err: obj a {Yf{rl{Ya{Rm{re{X whip (23204) – 110, mob a {Yf{rl{Ya{Rm{re {Dt{wi{Wt{wa{Dn{X (23204) – 87
Err: obj a {Cf{cros{Ct{X mace (23203) – 105, mob a {Cf{cros{Ct {Dt{wi{Wt{wa{Dn{X (23203) – 87
Err: obj a {bs{Dt{Wo{Dr{bm{X spear (23201) – 118, mob a {bs{Dt{Wo{Dr{bm {Dt{wi{Wt{wa{Dn{X (23201) – 87
Err: obj an {Dada{Wman{Dtine{X poleaxe (23202) – 100, mob a {Dt{wi{Wt{wa{Dn{X (23202) – 87
Err: obj a {Yf{rl{Ya{Rm{re{X whip (23204) – 110, mob a {Yf{rl{Ya{Rm{re {Dt{wi{Wt{wa{Dn{X (23204) – 87

Notice the BUG in there. Also, thats just some of what I get, I get a lot more of those, I just didnt want to spam
this screen. Then it just stops, when I hit ctrl C it says this.


Program received signal SIGINT, Interrupt.
0xb7f11928 in ___newselect_nocancel () from /lib/libc.so.6

Any idea how to fix that? That might be what is causing the crash?
31 Jan, 2011, Vfx23 wrote in the 7th comment:
Votes: 0
Oh, right, forgot to mention that it freezes when I try to log on. Doesnt say what it says when the mud is crashed. It just freezes.
31 Jan, 2011, Runter wrote in the 8th comment:
Votes: 0
In your post when you ran gdb it never crashed. You interrupted it. I.e. the program was still running. If it doesn't crash gdb obviously isn't going to tell you what crashed it. Those bugs are just logs from the game itself. They may not be that big of an issue. Freezing is a relatively broad term. It can mean you can't connect and it can mean the program is stuck in an infinite loop. Or it can literally mean the program has halted. In any event, those things aren't crashes.
31 Jan, 2011, Vfx23 wrote in the 9th comment:
Votes: 0
I know when it froze up it didnt crash, since the guide said it would freeze up (pause). The crashing part is obviously still there. How can you play it then when it paused? Have to turn gdb off again? Wouldnt make much sense if you have to turn it off to play, and it crashes, and gdb doesnt capture the info than. The sigint Im guessing is a problem that needs to be fixed though? No idea what to do about all those Err:obj problems. Again, no one ever answered this part, if you get disconnected from shell (due to idleing for a couple of minutes, disconnects me) Is gdb still running when I get back on, or do I have to restart it?
31 Jan, 2011, Davion wrote in the 10th comment:
Votes: 0
Type 'continue' into the gdb prompt
31 Jan, 2011, Tyche wrote in the 11th comment:
Votes: 0
Vfx23 said:
I know when it froze up it didnt crash, since the guide said it would freeze up (pause). The crashing part is obviously still there.


This?
Program received signal SIGINT, Interrupt.
0xb7f11928 in ___newselect_nocancel () from /lib/libc.so.6

CTL-C issues a SIGINT. That's by intention.

Vfx23 said:
No idea what to do about all those Err:obj problems.


Those are messages issued by ROM when the objects held by mobiles are a higher level than the mobile. Change the level of the objects or mobiles, or do nothing. Those aren't really errors, just warnings that ROM issues to let you know there might be "balance problems" (for lack of a better term) with the areas.

Vfx23 said:
Again, no one ever answered this part, if you get disconnected from shell (due to idleing for a couple of minutes, disconnects me) Is gdb still running when I get back on, or do I have to restart it?


There are many reasons for you getting disconnected. None of them have anything at all to with PuTTY.
The most obvious reason for an inactivity disconnection is your router's NAT port timeout.
31 Jan, 2011, plamzi wrote in the 12th comment:
Votes: 0
Vfx23 said:
I know when it froze up it didnt crash, since the guide said it would freeze up (pause). The crashing part is obviously still there. How can you play it then when it paused? Have to turn gdb off again? Wouldnt make much sense if you have to turn it off to play, and it crashes, and gdb doesnt capture the info than. The sigint Im guessing is a problem that needs to be fixed though? No idea what to do about all those Err:obj problems. Again, no one ever answered this part, if you get disconnected from shell (due to idleing for a couple of minutes, disconnects me) Is gdb still running when I get back on, or do I have to restart it?


You can run gdb as a background process so it would stay up, like your mud does. Try using "nohup" in front of any invocation to make sure your processes don't terminate normally if your shell session closes.

I'm not sure what's supposed to happen whey you're attaching gdb to an already started process. It could be that your server has already crashed or stalled by the time you try to attach. But have no fear - gdb can be used to start & attach at the same time (see "man gdb"). Your command line would be something like: nohup gdb -e ./startup/rom –args (port) &.

I actually start gdb first and then set the target file and args manually. This requires the shell to stay open, but I don't have a problem with it closing (neither should you).

Here's how I debug usually:

>gdb
(gdb) set file ./startup/rom (or whatever path to your binary is)
(gdb) set args (port, & anything else you may need to pass as args to your binary)
(gdb) run

You should now be able to see the logged output printed to your shell window, and should be able to connect to your server in another window. If/when it crashes, gdb shows the crash line. You can then do:

(gdb) bt (backtrace some frames before the crash)
(gdb) frame # (jump to a frame of interest)
(gdb) print (var_name)

if/when it stalls (usually an infinite loop), you can do Ctrl + C, then "bt", etc.

"Continue" is the command to proceed after a breakpoint, but I doubt you have any set. Read the man pages on how to use breakpoints or type "help breakpoints" inside the (gdb) prompt.

Hope this helps.
01 Feb, 2011, Vfx23 wrote in the 13th comment:
Votes: 0
nohup gdb -e ./startup/rom –args (port) & isnt booting the mud.

Right after I type that and hit enter, it shows this

nohup: ignoring input and appending output to `nohup.out'

when I type ps ux after I did it, it shows.

[1]+ Done nohup gdb -e ./startup/rom –args 8310

Isnt booting the mud though.

I just did this now, not sure if it makes a diff and works or not.

Went to area dir, where my startup file is and booted it normally

Then did.

nohup gdb -e ./startup/rom –args (port) &

Then looked at ps ux and attached it with the pid of ./startup
01 Feb, 2011, Runter wrote in the 14th comment:
Votes: 0
I don't think you need to use the startup script (maybe you shouldn't at all) with gdb.

nohup gdb -e ../src/rom –args (port) &

is closer. Obviously replace port with your port. In any event, the command lines you posted look like they aren't working for a good reason. startup isn't a directory so how is ./startup/rom even a valid path? Maybe you should reread the gdb guide again. It's very clear and specific for muds. And if you don't quite understand something in it ask about those specifics.
01 Feb, 2011, Vfx23 wrote in the 15th comment:
Votes: 0
ok I booted it via gdb, this is what I got now


Program received signal SIGINT, Interrupt.
0x0808b774 in reset_room (pRoom=0xb7baec00) at db.c:1726
1726 pExit->exit_info = pExit->rs_flags;

and this is line 1726 in db.c




pExit->exit_info = pExit->rs_flags;

Looks fine to me….

./startup 8310 & in area directory works fine, since my startup script is in area directory, how to boot it with src/rom/ I got from a gdb guide.

I tried booting it the way you said runter, this is what happens


notshowingusername@frostmud:~/cotb/1908/area$ nohup gdb -e ../src/rom –args 8310 &
nohup: ignoring input and appending output to `nohup.out'
[1] 8204

in ps ux:

[1]+ Done nohup gdb -e ../src/rom –args 8310

doesnt boot the mud though.
01 Feb, 2011, plamzi wrote in the 16th comment:
Votes: 0
Try print pExit->exit_info and then the other pointer to check if they're not null. Also use print to grab which room number (looks like a room) is not being loaded up properly and look at the file for that room. You can use print to output the value of any variables in the context of the current frame, not just the ones on the crashing line. The backtrace command also shows you what variables are being passed from one function to another–see if anything is odd there. Jump to earlier frames and examine the values of variables being passed down to the crashing point. If printing and frame jumping don't reveal anything, then set up breakpoints as needed. That's what debugging is all about.
01 Feb, 2011, Davion wrote in the 17th comment:
Votes: 0
SIGINT is not a crash. Type 'continue' into the gdb prompt.
06 Feb, 2011, Kyuss wrote in the 18th comment:
Votes: 0
Look at the guide that was posted again. You are debugging a crash so you should be using the core dump. That will tell you exactly where it crashed without you having to try and recreate the problem.

Use "ls -lt core*" to figure out what the name of the core dump is.

Then:
gdb rom core

to start debugging against the dump. Most of the time a crash occurs from accessing a null pointer or maybe accessing out of allocated memory via pointer arithmetic or array access. Looking at the line you have posted, pExit is probably null. You may need to trace backwards to see why it is null.
0.0/18