This is a very common error that people encounter, so let me take a few moments to address it.
First, the best thing about that error message is that it tells you exactly what happens, in a very polite way. We don't just come straight out and say, yep, "GDB crashed, ... again". We politely let you know that for whatever reason, GDB can't handle it's lunch and "terminated prematurely." Because, that is exactly what happened. This is not a problem with our integration. This is an unfortunate problem with the stability of GDB.
In most cases, you can circumvent the problem by turning off the "Autos" tool window, which is one feature of our debugger integration that expects GDB to handle errors correctly, ..., without that whole crashing bit, because crashing is, at least in my opinion, a rather restrictive way to handle errors.
It probably sounds like I'm coming down on GDB pretty hard here, but even with it's pecularities, it is still the very best free debugger available for the world of Unix. Our integration with GDB pushes it a little harder than some other GDB front ends, and unfortunately, in certain circumstances this exposes holes in GDB's overall stability.
You could argue that our debug Autos tool window should not send any invalid expressions to GDB, then GDB wouldn't have any problems. The expressions are simply surfed from the lines of code in proximity to the execution pointer. We are getting these from actual source code, which we can't really make a ton of assumptions about. The most logical thing is to take them at face value and expect GDB to not crash if we give it an identifier it doesn't recognize.
Anyway, let's say you have turned off "Autos" and GDB is still giving you fits. Here is what to do to further investigate the source of GDB's frustration.
1) Go to Macro > Set Variable ...
2) set def_debug_logging to 1
3) Start you debugging session and do whatever you do until GDB terminates.
4) set def_debug_logging back to 0
5) look in your configuration directory, there will be a file named "vs.log". Jump to the bottom of the log file and find the last command that was submitted to GDB. That's where GDB died, now you have a starting point to see if there is a newer version of GDB that fixes that bug, or maybe nag someone to fix GDB or maybe you can figure out that you can avoid that command by closing a tool window such as the threads, members, locals, or watches tool windows.