OK. I'm using AllocVec/FreeVec. So I should be using either AllocPooled or malloc (because it does it already).
The memory debugging tools (Wipeout, etc.) that have been mentioned before will directly hook into the exec.library management functions. You might get a clearer indication of where the memory was trashed than if you were using the 'C' runtime library malloc(), etc. functions which add some overhead and thereby obscure the problem. Note that Wipeout can (if you are lucky) only tell you which memory was overwritten, but not necessarily which piece of code caused it to be overwritten.
My advice would be not to put too much hope into tools such as Wipeout. Memory trashing bugs are extremely difficult to diagnose, not just under AmigaOS.
I my experience the only approach which works is by plastering the suspicious code with debug output and tests and stepping through it over and over again until you are confident that it works correctly without misbehaving. That's a lot of work waiting to be done, I can tell you
In a situation such as this I would begin by writing new debug code which displays which memory range is affected by the operations to be performed. What's the first byte that will be copied, what's the last one. Next, add code which verifies that this range is correct and only changes memory which your program is permitted to use (e.g. by having allocated it).
If you want to be safe, print that information and add a call to getchar() so that you will have to hit the Return key for the code execution to continue. That way, you will at least get to see the output before the system crashes.
Make sure that you can trust your code to do what you assume it does. When you are copying NUL-terminated strings, you need to be confident that only as much data is being copied as the memory it is copied to will hold. If your code works well with short strings, but not so much with long strings, you'll have to work on your boundary checking.