Sat Mar 27 22:55:51 2004 :: Loading asteroids...
Sat Mar 27 22:55:51 2004 :: [*****] BUG: fread_word: EOF encountered on read.
Sat Mar 27 22:55:51 2004 :: [*****] BUG: Cannot load asteroid file: ÿ
I know for a fact there is no asteroid with the name ÿ. So, any clues to why it might be giving me this error every time it starts?
Note: Using heavily modified SWR 1.0 and this asteroid code is all custom.
It's most likely caused by a problem with the variable type itself, or with the method by which you're reading the file. Could you post the file I/O code for it?
Also, as stupid as this may sound - open the file in pico on a *nix machine. Go to the end. HIt backspace until you're right next to the last character in the file. Then hit enter once and resave it. Often that alone is all it takes to stop the funky symbols from showing up in the logs.
Ok, found out something more. If I delete all of the asteroids and start a new everything goes correctly with no asteroids. If I make an asteroid and reboot I get the same error. I'm thinking it must be something with saving the asteroid. Also, if I use do_showasteroid on it, it hangs up on the line where its either showing the starsystem's name or its home starsystem (a char variable). This is set to Terra as default (STRALLOC("Terra")). Perhaps I've got the STRALLOC/str_dup thing wrong again. Would you all mind clearing that up again? DISPOSE goes with str_dup? Or what.
Ok, well, I've decided that I was going to put this into a snippet anyways, so here is the code (not the snippet).
http://ew.xidus.net/code/3.0a.c
http://ew.xidus.net/code/asteroids.h
Go ahead and take a look. If you want this added to your mud then feel free to use that or wait till I release a more tested version. I *THINK* that code in the .h file is the stuff I'm using in my mud, however, I'm not 100 percent positive. Let me know what you think, especially you guru's. You can prolly find a whole shit load of stuff thats wrong with it, but I think its pretty good for one of my first projects.
Actually, I see a few minor things wrong with that code already. I'll go ahead and update it tomorrow, however, that code is still what I'm using (except for a few modifications). I will finish the area variable implementation the right way also.
Quick run through of the code, and I see a few things. You used fread_string_nohash on filename, but initialized it with STRALLOC. Not a huge things, but its there. Also, this:
sprintf (aName, fread_string(fp));
Is a small memory leak.
Also, double check what the asteroid list looks like, as opposed to the individual asteroid files. Looks like you might have a bad asteroid linked into the list.
Ok, I think I got all that fixed. Not sure if aName = fread_string(fp); is a suitable memory leak fix, but I'm sure you'll let me know. Anyways, I have since cleared the asteroid. I'll go make some asteroids and let you all know how it turns out.
The memory leak comes from the call to the fread_string(fp). fread_string returns a pointer to STRALLOCed memory. By doing aName = fread_string, thats better, just make sure that you use STRFREE on it afterwards ;)
One other thing I'm noticing in the fragments you've posted - when you're doing an fclose() call you aren't NULL'ing the file pointer afterwards. You should always do this because you never know when the OS will decide leaving such a thing dangling is bad. I remeber we all went through this some time back in the day when switching up from Redhat 6 to Redhat 7.
Sampson, the "fp" you are talking about goes out of scope anyway in a couple of lines, in that function. I don't see how the operating system can complain if you don't NULL a pointer like that.
Actually, the aName variable is only needed to search through the areas in finding the correct one. After that, it has no purpose. So, knowing that, does it really need to be allocated?
Also, would aName = fread_string( fp ); then STRALLOC( aName ); be a suitable fix for the situation you described?
This is allocating it twice. You mean STRFREE (aName);
Quote:
So, knowing that, does it really need to be allocated?
The fread_string routine allocates inside itself, like this:
case '~':
*plast = '\0';
return STRALLOC( buf );
Thus, the string is already allocated, and must be freed if you don't want the memory leak. It doesn't matter what you plan to do with it, if anything.
Now this code will not have a memory leak, because fread_word does not allocate memory. However it has a different problem. fread_word does not allocate memory because it returns a pointer to a *static* buffer. Thus, word1 and word2 in the example above are the same piece of memory, and word1 is no longer what was read, because word2 has now replaced it.
Ok, I got the showasteroid thing ironed out. I'll format it later. Anyways, I created a new asteroid with the filename terra1.ast. This is what was in the file.
#ASTEROID
Name Rigel~
Filename terra1.ast~
Home Terra~
Type 1
Stype 1
Hp 4000
Maxhp 4000
Speed 100
Timer 0
End
#END
Thats after I set some stuff and use resetasteroid on it. Next, I shutdown the mud. I rebooted, and in the startup log I get:
Where exactly are you referring to? What function?
It appears it is having trouble in load_asteroids where it is loading the second asteroid using fread_word. Perhaps its a problem given when writing the asteroid list? If I remove all the asteroids then it goes away. However, if there is one or more asteroids then the above situation is the result, with the fread_word error and that messed up y with the two little dots.
This seems to have the wrong file name in it. Why I cannot say. Perhaps use gdb to step through the load asteroids function to see what is going wrong.
I think I'm going to go through it with gdb (not really sure how, guess I'll have to go read that tutorial again). If I can't find why then I'll rewrite the functions and see what turns up. I'll keep ya posted. However, if you find anything else please tell me so.
Ok, well, I've been stepping through load_asteroids and I'm not sure exactly what I'm looking for. It appears that the filename variable gets messed up when the for loop loops a second time, thus making it ÿ. However, before the loop has gone through once it is this:
$9 = 0xbffffa98 "Èúÿ¿Ì\035\v\b"
Got this another time:
$1 = 0xbfffeb18 "Hëÿ¿Ì\035\v\b"
I see the ÿ in there, but I don't think thats the point. I'm go gdb expert, so I really have no clue what all of this information means, I just know that the second time fread_word is called it doesn't read the next word correctly. Perhaps it isn't reading the next line?
The first thime the loop is called it reads the word using fread_word it does it correctly:
I think I found something. I was stepping through the load_shuttles code and found out that just a tiny bit later on in that loop, before filename gets redefined it reads "END", which is at the end of the file of course. Anyways, in my instance, it read End instead of END. Perhaps the problem is in fact in fread_asteroid.
// extract_asteroid( asteroid );
// asteroid_to_system( asteroid , starsystem_from_name(asteroid->home_system) );
I then set up an asteroids directory, and put into it your asteroid.lst file, and your terr1.ast file, make a copy of that asteroid and put the copy also into the asteroid.lst file (so I would have 2) and ran it. It seemed to work fine ...
Sat Apr 17 08:46:45 2004 :: Loading asteroids
Sat Apr 17 08:46:45 2004 :: Loading asteroids...
Sat Apr 17 08:46:45 2004 :: Done asteroids
So, unless the commented-out code does something strange to memory (and you could test that by commenting your copy out too) I cannot explain it. :)
I'll try commenting that stuff out and seeing what happens. Might be some confilict with other code in my codebase ::shrug::. I have no clue what that would be, but I guess you just never know. Would be kind of silly to have that nice piece of code and my own mud not be able to bennefit from it. We'll see what happens. Thanks.
I probably didn't put them there. The reason I commented them out was to avoid the compile error. They had other structures that I didn't want to bother with. The main thing I was testing was the reading of the asteroid file, not what became of it once it was in memory.
Hmm, I just thought of something. What exactly is the significance of using extract_asteroid in the load_asteroid_file function? The starsystem will ALWAYS be NULL making the function return immediately. Not only that but also extract_Asteroid is called within asteroid_to_system.
This allows the code to handle the addition of the asteroid to a system. Anyways, fixed version is at http://ew.xidus.net/code/3.0a.c if you wish to have a look. If not, you can just wait till the snippet version comes out. :)
Thanks to everyone, especailly Nick who got me lookin in the right spot.
Ah, finally, the glorious day. I have officialy released version 1.0 of the Asteroid snippet. You can download it from my web site by going to http://ew.xidus.net/modules.php?name=Downloads&d_op=viewdownload&cid=1 and finding the one called Code Driven asteroids. Thanks to everyone who helpped!