I've found a solution, and while it is a workaround, I have an idea of what is happening.
1) in any debugging situation, there are a lot of lines of code and dead breakpoints that are no longer needed.
2) I've never seen this problem in a straight C program, or at least, don't remember it.
3) this is in a C++ program, with virtual functions and lots of inheritance
What I think is happening:
The program compiles properly, links properly. However GDB looks at all the breakpoints and tries to nail down an address for them, even if the line of code doesn't exist or the breakpoint is not active.
This seems to break the load. However, if so, then GDB gives you a completely useful error message "socket error"
I looked this up when trying to report a GDB error. Yes, it is one, yes, they know about it. They've known about it since October of 2018. It hasn't been fixed yet.
If you can't fix it, or work around it, your project goes into a complete halt. All of the above is sheer conjecture based on the error messages, though.
Workaround:
When you get this error message, delete all the breakpoints (I decided to just shotgun the problem) that exist except for the first one in main, which is guaranteed to exist.
reload (I use F11), it should work.
Observation:
What I wrote about the various memory models may or may not be valid for other errors. Static or dynamic allocation may be another problem. What I suspect is that in changing memory models, I deleted various breakpoints. This particular explanation seems to work more reliably than the memory models, so with a bit of thought, it does make far more sense. I have no idea why the memory model used (new/malloc/static allocation) would make a difference. It seemed to work, though, but I think that the breakpoint handling was the real cause of the problem.
Conclusion:
I don't expect GDB to fix this anytime soon. I suspect that C++ with the virtual pointers makes the job of the debugger more complex, although that is just a suspicion.
This solution seems to work reliably.
