free freeing data twice or data that shoulnd't be freed
 

Maybe I'm declaring top->desc wrong but where I don't see it




---------- Post added 10-02-12 at 08:26 PM ----------

on this topic anyone know of a better debugger for linux?

---------- Post added 10-02-12 at 08:27 PM ----------

or how to debug this problem better?

You're writing past the end there.

valgrind is often helpful for this kind of thing.

still crashing

also if you add top->next = NULL;

after line

top->descr[strlen(desc) + 1] = 0x00;

top->name equals nothing. wierd.

now it seems to be when freeing name

Hi.

Let's debug your program using valgrind.
Okay, we have invalid write on line 31:
This bug has already been discovered by ntubski. And we will see that the same error occurs two more times in the program. You allocated only one byte for ch, but on the next line (N31) you try to assign zero value to the second element of string ch. C uses zero-based indexing: first element has index 0, second element -- 1 etc. So to fix this bug you should write
(BTW why you use one-character dynamic string here instead of just char ch;?)
Fixed.

Repeat the procedure:
What's wrong with line 36:
? Looks good. But couple of lines above we see
And we also see your error message "Error opening hometown.map". There are no such file as ".hometown.map" in my /tmp directory, naturally. The program tells us that there are no such file and just continues execution! Not good!
Fixed.
Continue:
Oh no, not again..
Line 68:
Can we write to top->name? Did we allocated space for it?
Hmm.. Yes? NO! What is top?
It is a pointer, its size is something like 4 or 8 bytes. Hardly enough.. One should write
Fixed.

Continue:
Invalid writes on lines 70, 74:
Again, you allocate array of strlen(name)+1 bytes and write to the last element, which should be (srtlen(name)+1)-1 = strlen(name):
Fixed:
Hurrah!

I'm sorry I didn't include .hometown.map I thought I gave you everything you needed to debug and I myself
came up short. I must say I am much oblidged to you, Firstfire. top = malloc(sizeof(struct areas));
was exactly the problem. everything else is actually really cool.

Again thanks to Firstfire. I read it fifteen times and fifteen times I missed it.
And special thanks to Ntubski for pointing out my character.
Sharing my Cool skeleton project:
http://o0oo0.net16.net/shared

ch is a pointer cause fread doesn't like plain characters for some reason.
heres .hometown.map
http://o0oo0.net16.net/shared/.hometown.map

errigour, if you really think that post was helpful, please click on the "Yes" (bottom right corner). Firstfire made a very good job.

fread() wants an address to write to, you can use the address-of operator, &:
Although if you're reading a single character it's easier to use getc():
Oh, and regarding the malloc() for top, you can also use:

I can't figure out what you are doing, linked-listing?
I think you are making life very difficult for yourself.

Why are you poncing about with malloc may I ask?
It's a recipe for mistakes avoid if you can.

If you must you can use strdup(3) to copy strings.

If it's a fire-and-forget application don't even waste your time calling free
the OS will recover any allocated space when you exit.

And don't do everything in one main function unless it's very trivial.
And I wouldn't use fread if I can get away with using stdio.h
(Let the OS do the work where you can and use your time for the interesting stuff).

ddd is a good front end for gdb.

well im using malloc because I can't get everything to compile right. I'm being difficult intentionally to master what I cannot do casually.

since you mention ddd maybe you can help me use it.
My program seems to be changing the address of char name[0] to 0x00. or I think because strlen of name = 0;
so how can I use ddd valgrind and gdb to find where the registry error is easily if I can. maybe you could show me an example use of ddd for this.

char area_map[10000][10000];
crashes my program
but when its not there the program runs great

If you search for other threads on "stack size" I'm sure you can easily find both an explanation of the cause of the crash, and several alternatives for making it work.

One example is:
http://www.linuxquestions.org/questi...2/#post4688720

In the example in that post it is important that the call to increase the stack limit happens before the call to the function that includes the declaration of the large array. I think C99 allows you to declare the large array within a function after doing work, such as increasing the stack limit, earlier in the same function. That might work. With certain added tricks specific to C99, it could work reliably. But in most cases the compiler will move the stack allocation to the beginning of the function, so changing the limit earlier in the same function is not good enough. It needs to be changed in a different function executed before this function is called.

I expect you want that array declared in main() in some program similar to the one at the top of this thread. In C, that makes it very hard to execute code before the function is called. There are other methods, but I suggest you have too much code in main anyway. Consider moving almost everything from main to some other function called by main. I would tend to leave inside main certain steps like opening of required files (".hometown.map") and aborting if those files are missing, then pass the file pointer to the function that takes over most of main's previous job.

.hometown.map:
http://o0oo0.net16.net/shared/.hometown.map

Can I ask one more thing here instead of posting:
the code above height is 501 width is 1001.
top->area_map is
char **area_map

is that a stack problem or am I defining it wrong?
i really gotta know how to do this thanks.

char area_map[500][1000]
it gives a segmentation fault at
top->area_map[0][0] = area_map[0][0];

You are defining it wrong (or allocating it wrong). It is not a stack problem.

char **area_map together with area_map[y][x] implies area_map points to a vector of pointers and each of those points to a separately allocated vector of data. You could replace the single allocation step with multiple allocations to build up the space implied by your current declaration and access code. Alternately, you could change the declaration to fit your existing allocation and access:

I think that would be:
In ANSI C, that method only works when the width is know at compile time (the height can still be decided at run time). The multi layered allocation lets both width and height be decided at run time. I think C99 and/or some gcc extension lets you use the declaration I suggested and still replace the 1001 with a variable. But I don't program in C99, so I might be confused on that detail.

what do I do?

I was editing some extra details into my above post while you replied, so maybe it answers that now even if it didn't when you first read it.

doesn't matter I found the answer thanks for all the help.

Here's the answer i think might be off by one:

Change that to

Got another multi demension array newb question:
I'm guessing because my program wont let me define the top elements of an array(not sure if my math is
wrong). Do I have to declare one extra number in both the height and the width of my area_map array?

just talkin about the local array not the structure.

It works like that im gonna leave it like that I just need some kind of reassurance that its breaking because
of that is all thanks alot.

also does allocating memory use ram or does it use hard disk space?

An array of size N has valid indexes from 0 through N-1 inclusive. Index N is not a valid index of an array of size N.

Not exactly.

If you allocate a lot of memory, that just uses virtual address space (in "demand zero" mode). It doesn't use ram nor hard disk.

As you write to each page (aligned 4KB portion) of the allocated space, that page is forced to exist in ram. If you are short of ram, then forcing some page to exist in ram may push some other page (maybe part of the same allocation) out to swap space. If you are also short of swap space then it may force the OS to kill some process.

what about my maximum ram I only have 512 when will my program cease?

also that means I have to declare 1000 extra bytes just to have an array. seems kinda dumb.

You seem to be missing the point. Think about an array
char[3][3];
I showed indexes in blue and showed possible contents a .. i. There is no "extra". A 3x3 array has nine elements and you can use all nine. You can't use index 3, because the starting index is 0.

Or maybe you meant the multi-level allocation to allow the char** declaration to be correct. For a 500x1000 array, that multi-level allocation costs a lot more than 1000 extra bytes. Each allocation has overhead, plus the pointers are it least 4 bytes each.

If you worry about that overhead, use the alternate declaration that allows you to malloc a single chunk.

But at 500x1000, these details don't matter. That is 500KB of data plus about 6KB of overhead. That is one tenth of one percent of your total ram.

But that is 100MB. That is a big enough fraction of your ram to take seriously, especially to ask why you want to have one version of that on the stack apparently just to copy it to another version allocated differently.

Assuming you have a decent size hard drive, I suggest you allocate a few (2 or 3) GB of swap space, so that when your program uses too much memory it will just get very slow rather than crash. That should make such problems easier to diagnose, quantify and correct.

Thankyou
SOLVED