how to measure free RAM

What makes you think that filling up all available memory is the reason for your problem? A "kern-exec 3" can have many different reasons.

Did you already debug and check where the error occurs? (Not with some kind of "memory debugger", as you asked, but with the "normal" runtime debugger.)

---

Well, correct me if I am wrong - but memcpy does not allocate any memory, it just copies it, right? I don't see how memory could get full at the execution of a memcpy, then. Are you sure your pointers are ok, and enough destination memory allocated?

Anyway, a quick use of forum search (box top right) for "free memory amount" gave me the following:
http://www.newlc.com/topic-3151

---

Oh, why didn't you say so from the start?

Tint User::AllocSize(TInt &aTotalAllocSize) will return in the argument, the total number of bytes in your heap at this point.
add it to User::Available() and you will see how big your heap chunk is currently.

To measure stack usage, you can save a pointer to a stack variable in the very begininig of your program, and then compare this to a pointer of any stack variable later.
along these lines:

TInt gStackAddress;

TInt E32Main()
{
TInt firststackpos;
gStackAddress = (TInt)&firststackpos;

// [...] Rest of entrypoint function
}

TInt GetBytesOnStack()
{
 TInt dummy;
 return gStackAddress - (TInt)&dummy;
}

malloc will "under the hood" result in a call to User::Alloc, since that is the native symbian API for memory allocation, so this will work for that too.

TInt numbytesonheap = 0;
TInt cellscount = User::AllocSize(numbytesonheap);
TInt biggestblock = 0;
TInt available = User::Available(biggestblock);

"numbytesonheap" would be the total sum of bytes allocated in all calls to malloc.

"numbytesonheap + available" would be an approximate size of the heap chunk, but a more exact number can be got through:

User::Heap()->Size();

This is the number of bytes actually allocated to your program at this point, "numbytesonheap" is just how many bytes currently in use.

"biggestblock" is the biggest continuous block in the heap. If you try to allocate a bigger block then this in one call, then the heap will have to try to grow, even if there is more bytes "available".

If "biggestblock" is a lot smaller then "available" that could mean heap fragmentation caused by bad ordering of your malloc and free-calls, creating lots of small "holes" in the heap, and therefore make your program use more memory then it really needs.

Its important to remember that "available" is just the number of bytes currently available _without_heap_resizing_. The heap will automatically grow when you try to allocate more then "available", until it reaches its max size.