[Bug libstdc++/70548] New: gdb pretty printers hang and spin cpu in gdb session.

[smark at datto dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70548

Bug ID: 70548
   Summary: gdb pretty printers hang and spin cpu in gdb session.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: smark at datto dot com
  Target Milestone: ---

Created attachment 38192
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38192&action=edit
stack trace for spinning gdb.

At first I opened this bug, 

https://sourceware.org/bugzilla/show_bug.cgi?id=19894

because I had no idea who owned the pretty printers, they referred me here

gdb spins a cpu and hangs, and the stack trace shows its buried in the pretty
printer. When I disable the pretty printer, I have no problem except that I
can't see my variables in the debugger. :-)

The stack trace is attached.
Thanks.

[Bug libstdc++/70548] gdb pretty printers hang and spin cpu in gdb session.

[smark at datto dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70548

--- Comment #2 from stu mark  ---
this finally got so annoying I did something about it.

This is not the correct fix, but it seems to keep gdb from hanging and as all I
really want to do in life is debug my program, I don't care if it's not
perfect, I just care that I can continue to debug.

in varobj.c

line 778 or so  (this is gdb 7.12.1 I'm playing with here)

  /* We ask for one extra child, so that MI can report whether there
 are more children.  */
  for (; to < 0 || i < to + 1; ++i)
{ 
  if ( i > 100 ) // stu fix for hanging when to = -1
break;
  varobj_item *item;

"to" is -1 and that makes this loop spin forever

so I added the stop at 100 figuring 100 whatevers is enough for me.

[Bug libstdc++/70548] gdb pretty printers hang and spin cpu in gdb session.

[smark at datto dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70548

--- Comment #4 from stu mark  ---
I left that more for Henrique Andrade.

If there's a problem with the pretty printer, and a lousy hack like this can
keep gdb from hanging, to me, it's worth it.


I don't know which pretty printer was having the problem, and it happens
randomly in various bits of code, and not consistently, so I can't really tell
which printer is hanging. If you have suggestions on how to figure that out,
I'll give it a go.