The debugger has knowledge about where the code for functions in your program begin and end, either because this information is provided in debugging data or because it uses any external symbols visible in the executable to provide rudimentary information.
When the stack is in a proper state, it contains a return address to the calling function and, somewhere above that, a return address to a higher-level calling function, and so on. While you are executing various debugger commands, it uses these return addresses (and other information on the stack and in the state of the process) to show you the names of these functions. This requires looking up the return address in the debugger’s knowledge about where the functions are.
Once you overflow a buffer and corrupt the stack, the proper return address is destroyed. Instead you have a different address (one pointing to your shellcode if your exploit has worked). When the debugger tries to figure out which function this address is in, it fails, because the address is not in any of the functions in your program.
When this failure occurs, the debugger prints the error message you see.
Usually, the debugger can still perform basic functions: It can show you registers and memory in your program, it can still single-step and set breakpoints, and so on. It will have trouble doing things that require more complicated interpretation: It cannot figure out where stack frames are, it cannot find local variables by name, and so on.