my question is, is the argument, wm->wregions[y][x] not a pointer to struct?

No, wm->wregions[y][x] is a region.

wm->wregions is the beginning address of an array of region pointers. This array forms one dimension. Given that y is used as the index, one can visualize this array as denoting the vertical axis.

Each wm->wregions[y] element (where each is a pointer to another array of region's...) points to another singly-dimensioned array which can be visualized as representing the horizontal axis. Note the symbolism of x.

Now, im writing all of my regions to file, the file gets to about 2.7 megabytes and the program crashes(in the middle of writing a region).... some kinda overflow? what is it? Ive tried fputc, and fputs... hmmm.

H...the program crashes(in the middle of writing a region).... some kinda overflow? what is it? Ive tried fputc, and fputs... hmmm.

We haven't seen the code, so it is difficult to say what is the root cause, but things you will want to explore include:

Ensure all regions have been initialized. It appears you are doing a lot of dereferencing in your code, &:

reading from a nonzero random address will yield garbage. At this point, it becomes a question of whether the bit patterns found at such addresses yield valid values.

writing to nonzero random addresses will generate a fault.

Your structures contain many string addresses. If these addresses have not been initialized or assigned the address of memory acquired through malloc(), etc, then they are uninitialized as well.

Look at how much data is on the stack. At compilation, the size of the stack will be set. For "normal" usage, the system default should be adequate, but like all C-like arrays, array boundaries can be exceeded.

My suggestion is to write code which will output a region to stdout, or at least chosen parts. The purpose of this is to provide you a means of validating any arbitrary region structure which is being maintained. Until you can say with certainty that all structures contain expected data, dereferencing problems will continue to lurk.

I have managed to work around the save crash by having it create 40 "region files" when saving the world instead of one giant save file. The program now works up to the character generator, and only crashes now in macosx (works fine in bsd)

dont laugh at my code, i consider myself and "enthusiastic novice at C"

Edit: (gdb on macosx)

Code:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00007fff6076d300
0x00007fff80c8ec00 in strlen ()

Last edited by ocicat; 23rd September 2011 at 02:02 PM.
Reason: Screen output is easier to read by using [code] & [/code] tags.

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00007fff6076d300
0x00007fff80c8ec00 in strlen ()

...which is the tell-tale sign of a string which isn't NULL-terminated.

I haven't looked at your code yet (maybe this weekend if it is relatively small...), but is there a reason why you are creating such an elaborate structure based on pointers, calls to malloc(), etc.? Why not pre-allocate a fixed size array at compilation time? There can be valid reasons for allocating everything from the heap, but you take on deciphering the structure as a result.

I have managed to work around the save crash by having it create 40 "region files" when saving the world instead of one giant save file. The program now works up to the character generator, and only crashes now in macosx (works fine in bsd)

I looked briefly at your code. Given the behavior & error messages mentioned, I still am of the opinion that your code is walking into unallocated memory. Where, I did not discern. However, here are a few more thoughts on what can be done to find the problems:

I didn't determine whether wm->height & wm->width were being assigned only once, but these values are frequently used as upper bounds in for-loops when iterating through the overall structure. You will want to make sure these values aren't changed past the point of allocation.

I did notice that in write_world_file(), wm->height & wm->width are defined as type long, but the indexes used were of type int. Making the indexes the same type as the upper bound is a good idea.

Write independent test code on the side which simply creates the structure with anticipated fixed sizes, write to each location in the structure, and read & write to a file. Start with very small sizes & ensure that reading & writing works. Once this is verified, increase the sizes & ensure that reading & writing still works. I still believe that some memory access is happening past what has been allocated. A simplified test case will make it easier to pinpoint the problem.

IS it possible to have pointers to structs within pointers to structs within pointers to structs etc???

Yes, but recognize what you are really trying to ask:

Is it possible to store an address of a nested structure within an enclosing structure which will be set sometime during runtime?

The answer is still "yes".

Quote:

Am I making too much work for miself?

As mentioned before, it appears that you are writing all the code at once, then realizing that it needs to be debugged. Yes, this may appear daunting.

The solution is to break the problem down into smaller portions, & debug them one at a time. This is the secret of writing large applications -- break it down into more managable subsystems, & test, test, test.