Crashing, and attempting to gdb core

Posted by Zeno on Mon 29 Sep 2003 01:50 AM — 17 posts, 48,230 views.

Zeno USA Mon 29 Sep 2003 01:50 AM #0

Ok, the MUD crashes while I'm not on, so I go to the area directory, and here's whats in it.


area.lst    core.25240   export.are   haon.are      limbo.are.bak  newgate.are   srefuge.are
astral.are  core.25472   gallery.are  help.are      manor.are      pixie.are     unholy.are
boot.txt    core.28961   gods.are     help.are.bak  midennir.are   plains.are
Build.are   daycare.are  grave.are    limbo.are     newacad.are    redferne.are
chapel.are  dwarven.are  grove.are    limbo.are2    newdark.are    sewer.are

core.28961 would be the newest, so I type "gdb smaug core.28961" and this is what I get.


Core was generated by `../src/smaug 1801'.
Program terminated with signal 8, Arithmetic exception.
#0  0x080f755b in ?? ()
(gdb) bt
#0  0x080f755b in ?? ()
#1  0x080d1dc3 in ?? ()
#2  0x080a7a89 in ?? ()
#3  0x080a7355 in ?? ()
#4  0x420158f7 in ?? ()
(gdb)

How do I figure out what crashed it from this?

David Haley USA Mon 29 Sep 2003 02:56 AM #1

Looks like your makefile isn't generating debug data.

Two things I can think of to check:
- make sure the core files are actually generated by the 'smaug' executable (this is highly probable, but, well, you never know)
- make sure that the make file is generating debug info

Could you paste the relevant parts of the makefile? i.e. the parts that have compiler flags, should be the top of the file before the object file list.

Zeno USA Mon 29 Sep 2003 06:54 PM #2

Don't see any gdb/core info in the Makefile, so I'll post the main stuff.


CC      = gcc
#PROF    = -p
NOCRYPT =

#Uncomment to compile in Cygwin
#CYGWIN = -DCYGWIN

# Uncomment the two lines below if compiling on a Solaris box
#SOLARIS_FLAG = -Dsun -DSYSV
#SOLARIS_LINK = -lnsl -lsocket

#Uncomment the line below if you are getting undefined crypt errors
NEED_CRYPT = -lcrypt

#Intermud-3 - Comment out to disable I3 support in your code
I3 = 1

#Uncomment the line below if you want a performance increase though beware
#your core files may not be as much of a benefit if you do.
#OPT_FLAG = -finline-functions -funroll-loops -fdefer-pop -fstrength-reduce

C_FLAGS = $(OPT_FLAG) -O -g2 -Wall $(CYGWIN) $(PROF) $(NOCRYPT) $(SOLARIS_FLAG)
L_FLAGS = $(OPT_FLAG) $(PROF) $(SOLARIS_LINK) $(NEED_CRYPT)

David Haley USA Tue 30 Sep 2003 04:38 AM #3

For what it's worth, I have -g3 and not -g2.

According to the man page for gcc, you may also want to say -ggdb which means generate debug info specifically for GDB.

Do the game's log files give any indication where it's crashing? It's more than a little strange for there to be no stack frame information whatsoever. Why don't you try running the game, not with the startup script but by running it through gdb?

e.g.

cd area
gdb ../src/smaug
(in gdb) run 1234 (or whatever your port is.)

That might show you where the crash is, because you'll be running the MUD in special debug form, where GDB is aware of basically everything. You can even do function calls from the prompt here, which is pretty nice. This will probably help determine where your code is dying, if you can't get the core files to work right.

Oh, another thing I just thought of - make sure that your core files aren't limited in size. Do that by typing ulimit -a and seeing what it gives you for the core. If your core file size isn't big enough, it may be being truncated, which will completely prevent GDB from reading the symbols and whatnot. That might be your problem... not sure though, but at this point it seems the most likely.

Samson USA Tue 30 Sep 2003 02:04 PM #4

Just another observation, in my experience the command has usually been:

gdb -c corefile mudfile

And from there you do whatever debugging can be done. And it's not so unusual for the stack info to be completely hosed either. I've seen this happen many times :)

Quote:

Program terminated with signal 8, Arithmetic exception.

This right here is a big clue. You apparently divided by zero somewhere or did something else math related that the system didn't much care for. Check with whatever recent changes you made and carefully check the code to be sure you can't divide by zero.

Greven Canada Tue 30 Sep 2003 02:49 PM #5

I may be way off base, but I beleive that if your not seeing any information, it may be because your typing,

Quote:
gdb smaug core.28961

, when it should be,

Quote:
gdb ../src/smaug -c core.28961

. I've had the problem of not pointing gdb in the right place, or not have the binary there at all.

David Haley USA Tue 30 Sep 2003 05:14 PM #6

You don't need the -c corefile, typing:

gdb executable corefile

is sufficient. - Unless, of course, they've made that a new requirement and my version is too old, OR, they removed that requirement and my version is newer than yours. :)

However, yes, you certainly should be pointing it at the right direction; I hadn't noticed that you hadn't put the ../src/ in front of SMAUG.

Zeno USA Tue 30 Sep 2003 07:55 PM #7

I can gdb normally, but the MUD is crashing while I'm out somewhere, and want to use the core files to find out why it crashed. I'll edit this post after I do some things you suggested.

Samson USA Tue 30 Sep 2003 10:02 PM #8

Quote:

gdb executable corefile

Thats never worked for me. Must be one of those odd differences people like to throw into GDB for some reason. In any case, however you have to do it, having at least -g2 in your C_FLAGS *AND* in your L_FLAGS will give you enough debug info to go on. -g3 is only useful for debugging macros, and adds considerable bloat to your resulting *.o files and the executable.

Zeno USA Wed 01 Oct 2003 07:25 PM #9

Hmm, seems that one of my builders was on, and knows what was causing it. He was making items, then had typed "equipment" and it crashed. I tried to repeat this, wearing the same eq he was wearing, but it did not crash. I am using SmaugFUSS, so I think its a high chance that this snippet I installed is crashing it.


                    switch(obj->item_type)
                    {
                     case ITEM_ARMOR:
                       cond = (int) ((10 * obj->value[0] / obj->value[1]) );
                     break;
                     case ITEM_WEAPON:
                       cond = (int) ((10* obj->value[0] / 12) );
                     break;
                     default:
                       cond = -1;
                     break;
                    }
                    send_to_char("&C<&R",ch);
                    if (cond >= 0)
                          {
                          for (start = 1; start <= 10; start++)      
                                {
                          if (start <= cond)
                                        send_to_char("+",ch);
                                  else
                                        send_to_char(" ",ch);
                                }
                          }
                    send_to_char("&C>&W  ",ch);

This shows the equipment damage in "equip" displaying it ask "<++++++>" or something. I'm going to look this over now, to see what could have caused it, but if someone catches the problem before me, feel free to post whats wrong.

Greven Canada Wed 01 Oct 2003 07:53 PM #10

If your having a math exception, and that means that its being divided by zero, seems to me that v0 is set above 0, but v1 is still left at zero. That would cause the crash.

Zeno USA Wed 01 Oct 2003 08:15 PM #11

Ah, I see it now. Throwing a quick if check in there would fix it right?

EDIT: I've added this, and it works.


                     case ITEM_ARMOR:
                       if (obj->value[0] == 0 && obj->value[1] == 0 )
                         break;
                       cond = (int) ((10 * obj->value[0] / obj->value[1]) );
                     break;

Oh, and my core limit was set to 0. Why were cores still being created then?

Meerclar USA Wed 01 Oct 2003 09:17 PM #12

That check should work but what happens if value[0] isnt 0 but value[1] is? Granted, that should probably never happen but stranger things have happened. I'd advis change the && to || so that if either value is 0 it checks out instead of requiring both values be 0.

Zeno USA Wed 01 Oct 2003 09:43 PM #13

Yeah, but then if the armor was fully damaged, almost destroyed, and its value0 was 0, it'd not show it. I think... Well, something along those lines.

Samson USA Wed 01 Oct 2003 10:05 PM #14

You only need to check the value[1] to be sure it's not zero. value[0] can be 0, and as we all remember from math class, 0 / anything = 0 :) [except of course 0/0 which is still undefined :P]

David Haley USA Wed 01 Oct 2003 10:33 PM #15

Yes... having || instead of && could actually re-introduce the original bug and cause it to crash again. Samson's suggestion of only checking value1 is correct, since you only really care about value1 being 0 anyways.

Ah the joys of zero-division... :P Sometimes the most elusive of bugs can come from the most elementary (yet so hard to track down) bugs. You're fortunate that you have a builder who was alert enough to spot the cause of that; imagine if that had been somewhere else in the bowels of your code in a not-easily-traceable location. Now that would've been fun...

I don't know why the core file was being created even with a 0 file limit. That's really odd. Are you sure they were recent core files? Could you paste the text you get when you type ulimit -a ?

Zeno USA Wed 01 Oct 2003 11:20 PM #16

ulimit -a


core file size        (blocks, -c) 0
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
max locked memory     (kbytes, -l) unlimited
max memory size       (kbytes, -m) unlimited
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 7168
virtual memory        (kbytes, -v) unlimited

Changed the code to


                       if (obj->value[1] == 0 )
                         break;

I shoulda thought of that, but oh well.