access violation to reserved memory

"the error occurs in memset()command in debugging."

Excellent. So just verify the size of the block you try to memset(), and verify the target address. It shouldn't take long to figure out if you try to memset() memory that doesn't exist.

You are playing with the heap size - but are you verifying if your heap allocations actually returns the requested memory? You should catch allocation failures directly on the allocation instead of handing over the pointer to memset() and have memset() fail.

5800 doubles? Have you computed the total memory size needed for them? Is your heap large enough for that? Have you taken into account, that every heap allocation needs to consume a number of bytes extra for book-keeping?

"reaches to allocating 5800 doubles by memset "

Not sure what you mean by this sentence - memset() isn't allocating any memory. It just initializes the content of memory your program already needs to "own".

"the error occurs in memset()command in debugging."

Excellent. So just verify the size of the block you try to memset(), and verify the target address. It shouldn't take long to figure out if you try to memset() memory that doesn't exist.

You are playing with the heap size - but are you verifying if your heap allocations actually returns the requested memory? You should catch allocation failures directly on the allocation instead of handing over the pointer to memset() and have memset() fail.

5800 doubles? Have you computed the total memory size needed for them? Is your heap large enough for that? Have you taken into account, that every heap allocation needs to consume a number of bytes extra for book-keeping?

"reaches to allocating 5800 doubles by memset "

Not sure what you mean by this sentence - memset() isn't allocating any memory. It just initializes the content of memory your program already needs to "own".

5800 doubles needs almost 23KB memory.in lpc1788 i can use at least 64KB of RAM. do you think that this large amount can be problem of my program?

as you said, i debug the program and search in this site, i guess that this local array(5800 doubles) needs more _data_group memory. can it be true? if it is true, how can i increase the memory referred to _data_group.
i just consume 10KB of my RAM. can I allocate remained RAM to Local variables? can it solve my problem?

thanks for your helps.

i also changed heap size more than 24KB and also increase stack size.i don't know how i can determine how much heap and stack size the program needs, so i just increased it as much as possible! i know it's not a good method.

A float would require 4 bytes. A double - for a compiler that supports the double data type and doesn't downgrade it to a float - would require at least 8 bytes. So an array of 5800 double would be at least 46400 bytes. That's twice your heap size.

Why are you experimenting? The compiler can tell you the required size of the array with the operator sizeof. And malloc() would not return a real pointer value if the heap is too small so the allocation fails. Any call to malloc() or calloc() should verify the returned value.

So how can you not know if the program is able to perform all required heap allocations?

yes, you are right.so, how can i use compiler to tell me required heap size?
i don't know what you mean by the last line:
So how can you not know if the program is able to perform all required heap allocations?

also what is your opinion about _DATA_GROUP that i mentioned in last post?

thanks.

>>i don't know how i can determine how much heap and stack size the program needs

So evaluate it. Instrument the malloc/free so you know the types and maximal usage cases. Evaluate the maximum stack depth, see how much it needs dynamically by marking the stack and seeing the high-water mark, look at the static analysis/call tree generated by the linker, and your own assessment of what the heck your code does or might be expected too.

The kinds of double array described takes 46KB

As Per notes now can you not check the allocated pointer before using them, the library should clearly indicate if the heap is exhausted or too fragmented to fulfill the request. Add some diagnostics and instrumentation so you know what your code is doing, and how it is failing.

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