access violation to reserved memory

thanks for your help. actually I'm not so experienced in debugging such sophisticated programs and it is my first experience . i can honestly say that i didn't understand your last post.excuse me.

NULL check all allocated pointers, and have your code propagate errors rather than crash and die.

Instrument your code so it outputs diagnostic information to a console, and build/track structures so you can output details about the internal state. ie so when you get a Hard Fault, or failure, you can output information about the heap, your allocations, the potential for leaks or fragmentation.

Evaluate code that is not hardware specific on a PC.

The linker outputs call tree and stack details, review it.

Pick up some books/articles on debugging.

thanks a lot for your helps and quick answers.
i will try to debug my code as you said .i will post my debugging results.

thanks.

When you call malloc(), you need to supply the size of the memory you wants allocated.

So you obviously must know the size value you send to malloc(). Which means you must already know that an array of 5800 double values is way larger than 24kB. Or aren't you using the sizeof operator to compute the size of the array?

If you do know that 5800*sizeof(double) is 46400 bytes, how can you even try to run your program with a heap that is only 24kB? And you claim it's 24kB _after_ you have already spent time making it bigger and bigger...

And haven't you read the manual documentation for malloc()/calloc() and noticed that they return NULL if it fails? So how come you have random failures in memset() after malloc() has failed? Why not having code like:

p = (double*)malloc(count*sizeof(double));
if (p == NULL) {
    // Failed the allocation.
    return FALSE;
} else {
    memset(p,0,count*sizeof(double));
    ...
    return TRUE;
}

Another thing - if you use memset() to clear the allocated array to zero directly after having called malloc(), you can replace malloc()+memset() with a single call to calloc().

Remember, that it is your task to read the manual for whatever function you are calling. If there is some information you don't understand from the manual text, then come back and ask in this forum. But never make use of a function without having spent time reading the documentation. Then you would know how to figure out if malloc() managed to allocate the buffer or not.

In the end, _you_ must spend time making sure that _you_ actually understands the meaning of every line of source code. Don't spend time trying to debug the complete program, as long as there are individual source code constructs you don't understand. Debugging a complete program requires you to already understand the meaning and function of the individual lego pieces that has been used to build the program. If you don't understand the individual building blocks, then you can't understand the complete program. And then you can't really expect to be able to debug it. You can't debug black magic, so you must spend time with manuals and programming books until the magic stops being magic and becomes logic. Then you will also be able to see when the program does something illogical, and can fix it.

Rome wasn't built on one day. Don't take on too big tasks directly. Start with something simpler and then increase the complexity as you learn. That's more productive and also much more fun.

yes, you are right. my fault was exactly something you said. i am very appreciative because of your helps and recommends. surely your recommends will help me to be a better programmer.
i will do exactly as you said and come back after understanding all those you said.
thanks again for spending your time to solve my problem.
bye