Memory leaks are really a non-issue once you understand how memory management works. To deal with them, you need two things:
First, get a debugging memory manager. I don't know what's available for C, C++ or Fortran, since I'm a Delphi developer, but in Delphi there's a memory manager replacement called FastMM FullDebugMode that will keep track of your allocations and deallocations, and alert you at the end of the program if you've leaked anything. It provides a stack trace, type information, and other useful debug information for each leak, which makes them very simple to track down and fix. You ought to have something similar available for other languages.
Second, you need to understand how to structure memory allocation to prevent leaks from happening. The technique for this can be formally stated as the Single Ownership Principle:
Each variable in your code has one and only one owner, and it’s the
responsibility of that owner to free the variable’s memory when it is
no longer needed.
What that single owner is will vary depending on what the variables are and what they're used for. Primitives, for example, are owned by the stack and will automatically be cleaned up when a function returns. Most objects, by contrast, are owned by another object. Those that aren't are generally local variables that should be cleaned up by the routine that created them before it exits.
Objects that are shared by multiple other objects do not have multiple owners; if you think of it that way you're asking for trouble. Instead, they should have one single owner, either a reference-counting system or a master object that you know will be around longer than any of the others.
When you internalize the Single Ownership Principle, you'll write a lot less code with leaks. And when you have a debugging memory manager to report on whatever you missed, fixing the few mistakes you do make will stop being a scary prospect.