Just as a followup to why assert will help, I recently used assert in a
C++ program. Here's the relevant code:
void Codes::encode(const string &in, const string &out)
{
ifstream fin1 (in.c_str(), ios::binary);
assert(fin1);
while( fin1.get(ch) )
{
ftable[(uchar)ch]++;
}
fin1.close();
}
if the file in.c_str() isn't valid, the ifstream won't be valid. I
typed in a garbage input file name, and with the assert, I get:
[EMAIL PROTECTED] proj2 $ ./huffman -i f827fdA*#h
input file is 'f827fdA*#h'
huffman: codes.cpp:114: void Codes::encode(const std::string&, const
std::string&): Assertion `fin1' failed.
Aborted
If I didn't have the assert in before the while, I'd get:
[EMAIL PROTECTED] proj2 $ ./huffman -i f827fdA*#h
input file is 'f827fdA*#h'
Aborted
Not very helpful, is it?
Admittedly you can get the same info by testing the ifstream yourself:
ifstream fin1 (in.c_str(), ios::binary);
if (!fin1)
{
cerr << __FILE__ << ":" << __LINE__ << ": "
<< __PRETTY_FUNCTION__ << ": "
<< " Error: no ifstream." << endl;
exit(10);
}
Or, in your case, making sure fp is valid.
Jeremy Hill wrote:
I don't particularly know what's going on, but the code is telling you
it is segfaulting trying to access fp.
Try adding
#include <assert.h>
at the top of __FILE__, then replacing:
934 fprintf( fp, "#O\n" );
with:
<>
assert(fp);
fprintf( fp, "#O\n" );
or:
assert(fprintf( fp, "#O\n" ));
At the very least, assert will give you some more information about
the next crash. Assert, next to GDB, is your best friend.
-- Jeremy
Dale Kingston wrote:
Ok well for a small while maybe a week my muds been having this odd
habit
(fit?) where it likes to crash while in fwrite_obj. The people it
crashs on
is random, but the thing that always remains the same oddly is the
number of
frams... At first I thought it was looping through an endless link
list of
items... but after looking at it none of the items are repeating... Here
GDB's input:
This GDB was configured as "i386-redhat-linux"...
Core was generated by `../src/rom 5000'.
Program terminated with signal 11, Segmentation fault.
Loaded symbols for /lib/libresolv.so.2
#0 0x081c7c5a in obj_data::fwrite_obj (this=0x41167c84, ch=0x41099138,
fp=0x87aac98, iNest=0) at save.cc:934
934 fprintf( fp, "#O\n" );
Now I'll save you the back trace but needless to say concistantly
fram 168
is always where the saving starts so thers always the same number of
frams
before it kills over
(gdb) info local
this = (obj_data *) 0x41099138
ed = (EXTRA_DESCR_DATA *) 0x0
obj = (OBJ_DATA *) 0x41167c84
paf = (AFFECT_DATA *) 0x829eba5
dot = (DOT_DATA *) 0x87aac98
pGem = (req_gem_mod_type *) 0x81c8866
buf = '\000' <repeats 12 times>,
"[EMAIL PROTECTED]/[EMAIL PROTECTED]
\000\003\000\000\000R∞#\b", '\000' <repeats 12 times>, "á1\e@", '\000'
<repeats
16 times>, "α═\016@", '\000' <repeats 186 times>, "d ", '\000'
<repeats 48
times
, "╖/α┐\n", '\000' <repeats 19 times>,
"\001\000\000\000R∞#\bΦ*α┐╪0α┐\013\000\0
00\000\000\000\000\000╕/α┐\000\000\000\000\003\000\000\000 ", '\000'
<repeats
112 times>, "R∞#\b", '\000' <repeats 220 times>, "╕╗\037\b≡/α┐", '\000'
<repeat
s 980 times>, "[EMAIL PROTECTED]"...
where_vnum = 35001
None of the values are bad.... Also the odd thing of this all is I have
signal handlers which for the most part catch everything. But for some
reason it doesn't catch this the mud just dies and my startup script
restarts.
Any suggestions? Could it be my saving function is taking too long so it
thinks it's looping endlessly?
Heres some surroudning source:
else
{
if ( obj->in_obj != NULL )
where_vnum = ROOM_VNUM_TEMPLE;
if ( obj->in_room != NULL )
where_vnum = obj->in_room->vnum;
if ( obj->in_room == NULL && obj->in_obj == NULL )
obj->in_room = get_room_index( ROOM_VNUM_LIMBO );
}
fprintf( fp, "#O\n" );
fprintf( fp, "Vnum %d\n", obj->pIndexData->vnum );
if (ch == NULL)
fprintf( fp, "WhereVnum %d\n", where_vnum );
if (!obj->pIndexData->new_format)
fprintf( fp, "Oldstyle\n");
if (obj->enchanted)
fprintf( fp,"Enchanted\n");
fprintf( fp, "Nest %d\n", iNest );
