I''ve got the situation, when HeapAlloc, which is called from some STL memory allocator, stops at the

  
DbgBreakPoint:
  int 3
  ret
  

In release mode it causes stack overflow, though there are no any recursion in the code, and there are no lots of auto variables. I''m using STL heavily while managing my data structures. What can be the origin of wrong heap operation in such a case?

When you hit that breakpoint, pop up the stack to your code. Are you trying to allocate something insanely big?

99% of the time, STL, win32 and the core C/C++ libraries are not to blame. They have these checks in them that will cause your debugger to stop inside these functions when they detect they''re not being used properly. Many do not understand this, and say "there''s an error in STL/MFC/HeapAlloc" when really that breakpoint is to let you know that the calling code (e.g. user code) is in error.

Thanks, Stoffel! You was right, as usual. I''ve passed a char* pointer to the std::string constructor, but the trouble was that after some mangling with that c-style string, the terminating \0 was lost. So that string became insanely huge. That thing was not obvious, because debug breakpoint was reached later, when trying to allocate some memory at other place of the code.
...I''m not blaming Win32 nor STL. Especially STL .
Just trying to figure out what am I doing wrong with it.