09 Nov, 2011, arholly wrote in the 1st comment:
Votes: 0
OK, that just sounds like a fun topic, but seriously, I'm trying to get my item_type in the dump and it keeps crashing and I think I'm doing it right.
/* start printing out object data */
fp = fopen("obj.dmp","w");

fprintf(fp,"\nObject Analysis\n");
fprintf(fp, "—————\n");
fprintf(fp, "VNUM | Active | Resets | Type | Description\n");
nMatch = 0;
for (vnum = 0; nMatch < top_obj_index; vnum++)
if ((pObjIndex = get_obj_index(vnum)) != NULL)
{
nMatch++;
fprintf(fp,"#%-4d | %3d active | %3d reset | %s | %s\n",
pObjIndex->vnum,pObjIndex->count,
pObjIndex->reset_num, type_flags[pObjIndex->item_type].name, pObjIndex->short_descr);
}

And the type_flags looks like:
struct flag_type
{
char *name;
int bit;
int settable;
};

What am I botching now?
09 Nov, 2011, Kline wrote in the 2nd comment:
Votes: 0
What is obj_index_data->item_type declared as? What is type_flags; a table, or only the struct you pasted?
09 Nov, 2011, Runter wrote in the 3rd comment:
Votes: 0
probably this bit:

type_flags[pObjIndex->item_type].name

But you should use gdb or a debugger to be sure exactly what is crashing it. I suspect whatever value pObjIndex->item_type is, is outside of the bounds of type_flags size.
09 Nov, 2011, arholly wrote in the 4th comment:
Votes: 0
Sorry, type_flags is a table with the structure of the above. So, I pulled up gdb and got this:
[~/ptmud/src]# gdb project core1
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-37.el5_7.1)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...;
Reading symbols from /home/m243bra/ptmud/src/project…done.

warning: core file may not match specified executable file.
[New Thread 12110]
Reading symbols from /lib/ld-linux.so.2…(no debugging symbols found)…done.
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `grep update_stocks'.
Program terminated with signal 3, Quit.
#0 0x0070c402 in __kernel_vsyscall ()
(gdb) list
340 * Memory debugging if needed.
341 */
342 #if defined(MALLOC_DEBUG)
343 malloc_debug( 2 );
344 #endif
345
346 /*
347 * Init time.
348 */
349 gettimeofday( &now_time, NULL );
(gdb) bt
#0 0x0070c402 in __kernel_vsyscall ()
#1 0x0020ffe3 in ?? ()
#2 0x00000001 in ?? ()
#3 0x08049edb in do_rp_ok (ch=0xa, argument=0x1000 "\204v\001") at act_comm.c:2753
#4 0x0804ad24 in do_group (ch=0xa, argument=0xd <Address 0xd out of bounds>) at act_comm.c:2575
#5 0x0804c368 in do_quit (ch=0x0, argument=0x8057800 "") at act_comm.c:2208
#6 0x00162e9c in ?? ()
#7 0x00149ca0 in ?? ()
#8 0x08057800 in do_nominate (ch=0x804b550, argument=0x149ca0 "") at act_info.c:3855
#9 0x080497f1 in _start ()
(gdb)

Which is the same problem I had with another crash, but it doesn't have anything to do with what I modified in db.c.

Arholly
P.S.: I continually thank you and if I was going to have more children, I'd name them Bytes.
09 Nov, 2011, Runter wrote in the 5th comment:
Votes: 0
"warning: core file may not match specified executable file."

That readout is probably garbage. The core has to match the compiled source. If you recompile, gdb the old core.. no match and garbage readout.

Furthermore,

"Core was generated by `grep update_stocks'."
and if this isn't enough

"Program terminated with signal 3, Quit."
Which indicates it wasn't even a crash.
10 Nov, 2011, arholly wrote in the 6th comment:
Votes: 0
OK, when I make it just pObjIndex->item_type, it gives me a number, which is fine, but doesn't help me. I want it to give me the name of the item_type. This is the table:
const struct flag_type type_flags[] =
{
{ "light", ITEM_LIGHT, TRUE },
{ "scroll", ITEM_SCROLL, TRUE },
{ "weapon", ITEM_WEAPON, TRUE },
{ "treasure", ITEM_TREASURE, TRUE },
{ "armor", ITEM_ARMOR, TRUE },
{ "potion", ITEM_POTION, TRUE },
{ "clothing", ITEM_CLOTHING, TRUE },
{ "furniture", ITEM_FURNITURE, TRUE },
{ "trash", ITEM_TRASH, TRUE },
{ "container", ITEM_CONTAINER, TRUE },
{ "drinkcontainer", ITEM_DRINK_CON, TRUE },
{ "key", ITEM_KEY, TRUE },
{ "food", ITEM_FOOD, TRUE },
{ "money", ITEM_MONEY, FALSE },
{ "boat", ITEM_BOAT, TRUE },
{ "npccorpse", ITEM_CORPSE_NPC, TRUE },
{ "pc corpse", ITEM_CORPSE_PC, FALSE },
{ "fountain", ITEM_FOUNTAIN, FALSE },
{ "pill", ITEM_PILL, TRUE },
{ "map", ITEM_MAP, TRUE },
{ "portal", ITEM_PORTAL, TRUE },
{ "phone", ITEM_TELEPHONE, TRUE },
{ "ammo", ITEM_AMMO, TRUE },
{ "bomb", ITEM_BOMB, FALSE },
{ "liquid", ITEM_LIQUID, TRUE },
{ NULL, 0, 0 }
};
11 Nov, 2011, arholly wrote in the 7th comment:
Votes: 0
Correction, when I make it just pObjIndex->item_type it kills the process and shuts down the mud, but when I gdb <file> core, I get what I posted before. I'm kind of confused.
11 Nov, 2011, Runter wrote in the 8th comment:
Votes: 0
I think you just need to read up about gdb and how it works. There's a few mud specific guides out there that I've found just by googling for it.

http://www.iguanadons.net/Using-GDB-to-D...
http://www.tbamud.com/content/using-gdb-...

and

http://www.cs.cmu.edu/~gilpin/tutorial/

for good measure.
11 Nov, 2011, arholly wrote in the 9th comment:
Votes: 0
OK, I do know how to use gdb, at least what is being taught in those tutorials, but what I am getting is what it is being outputted.
11 Nov, 2011, Runter wrote in the 10th comment:
Votes: 0
If you did know what was being taught in these guides you would know you weren't using GDB on the correct core. And that you should just be doing
Quote
gdb executable
set args port
run


Do whatever causes your game to crash, look back in that windows and see what crashed it.
11 Nov, 2011, arholly wrote in the 11th comment:
Votes: 0
I do that but it doesn't start up. I also know it is supposed to be done from the area directory, but it doesn't start.
11 Nov, 2011, arholly wrote in the 12th comment:
Votes: 0
This is what I get:
m243bra@brandonsplace.net [~/ptmud/area]# gdb ../src/project
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-37.el5_7.1)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...;
Reading symbols from /home/m243bra/ptmud/src/project…done.
(gdb) set args 9080
(gdb) run
Starting program: /home/m243bra/ptmud/src/project 9080
Detaching after fork from child process 22304.
Detaching after fork from child process 22305.
Detaching after fork from child process 22306.
Detaching after fork from child process 22308.
Detaching after fork from child process 22309.
Detaching after fork from child process 22310.
Detaching after fork from child process 22311.
Detaching after fork from child process 22312.
Detaching after fork from child process 22313.
Detaching after fork from child process 22314.
Detaching after fork from child process 22318.
Detaching after fork from child process 22319.
Detaching after fork from child process 22320.
Detaching after fork from child process 22321.
Detaching after fork from child process 22322.
Detaching after fork from child process 22323.
Detaching after fork from child process 22324.
Detaching after fork from child process 22326.
Detaching after fork from child process 22327.
Detaching after fork from child process 22328.
Detaching after fork from child process 22329.
Detaching after fork from child process 22330.
Detaching after fork from child process 22331.
Detaching after fork from child process 22332.
Detaching after fork from child process 22333.
Detaching after fork from child process 22334.
Detaching after fork from child process 22335.
Detaching after fork from child process 22336.
Detaching after fork from child process 22337.
Detaching after fork from child process 22338.
Detaching after fork from child process 22339.
Detaching after fork from child process 22340.
Detaching after fork from child process 22341.
Detaching after fork from child process 22342.
Detaching after fork from child process 22343.
Detaching after fork from child process 22344.
Detaching after fork from child process 22345.
../data/survey/survey.srv: No such file or directory
../data/survey/poll.srv: No such file or directory
copyover_recover:fopen: No such file or directory

Program exited with code 01.
(gdb)
11 Nov, 2011, arholly wrote in the 13th comment:
Votes: 0
OK, I managed to figure it out. Thanks for the help Runter. It was with your help I did get it figured out.
11 Nov, 2011, quixadhal wrote in the 14th comment:
Votes: 0
Oh good.. I'm glad that's settled before someone had to suggest more fiber.
0.0/14