Skip to main content
Harvey White
Harvey White
Senior III
August 17, 2019
Solved

Atollic 9.3 debugger has socket error, refuses to load.

  • August 17, 2019
  • 1 reply
  • 885 views

large complex project in C++.

When it fails to load, I get the following:

/home/build/gcc-arm-none-eabi-6-2017-q1-update/src/gdb/gdb/cp-namespace.c:343: internal-error: cp_search_static_and_baseclasses: Assertion `name[prefix_len + 1] == ':'' failed.

A problem internal to GDB has been detected,

further debugging may prove unreliable.

Quit this debugging session?

This is a bug, please report it. For instructions, see:

<http://www.gnu.org/software/gdb/bugs/>.

(y or n) [answered Y; input not from terminal]

/home/build/gcc-arm-none-eabi-6-2017-q1-update/src/gdb/gdb/cp-namespace.c:343: internal-error: cp_search_static_and_baseclasses: Assertion `name[prefix_len + 1] == ':'' failed.

A problem internal to GDB has been detected,

further debugging may prove unreliable.

Create a core file of GDB? (y or n) [answered Y; input not from terminal]

Obviously, I can't have unreliable debugging so the debugger shuts down.

Gnu.org already has this bug listed, but from October 2018.

Either no progress or no duplication.

Anybody know what's causing this? It's obviously in the code, but what? name too long? indirect pointers to virtual functions, something that compiles but the debugger chokes on?

I can shotgun the problem, but I'm just doing thing and hoping that it'll fix the problem.

Would going to a different debugger work? If so, how to do that? Different debugger settings? didn't see much of that either.

This topic has been closed for replies.
Best answer by Harvey White

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.

1 reply

Harvey White
Harvey WhiteAuthorBest answer
Senior III
August 22, 2019

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.

Terms & ConditionsAccessibility statement