cgdb hangs with 100% CPU usage on OS X Mavericks

[cgdb]

cgdb hangs with 100% CPU usage on OS X Mavericks

[oblitum]

Well, in the end, regarding the other subject I mentioned at #46, I've also verified that there's no issue with tmux specifically, I have disabled it but still it seems that on Mavericks default terminal emulator I can't get feedback of the cursor position in the source window, it may be an issue with ncurses or Terminal. I just can't see where the cursor is pointing to so I can set the breakpoints easely.

[brasko]

On Sat, Jul 19, 2014 at 11:12:23PM -0700, Francisco Lopes wrote:

This happens when allowing the debugged process to continue until termination:

This is the backtrace taken with LLDB (weirdly, GDB is unable to work properly when attaching to a running process on Mavericks):

What happens if you do this?

g++ -g -o sample sample.cpp
cgdb ./sample
b main
r

Does this work, or same errors?

Bob Rossi

[oblitum]

@brasko Hi, it hits the breakpoint, then after continue it hangs as before.

[oblitum]

I can confirm this is not related to the latest changes. It's just something to do with Mavericks (or gdb/ncurses in it) :-S
I've tested it in the commit before the last two.

gdb version is 7.7.1.

[brasko]

On Sun, Jul 20, 2014 at 03:03:11PM -0700, Francisco Lopes wrote:

I can confirm this is not related to the latest changes. Just something to do with Mavericks :-S

Do you believe this to be a bug in CGDB or should I close the issue?

Bob Rossi

[oblitum]

@brasko I didn't check it further, so I can't confirm on anything. It may be a hidden bug in the interaction with other libraries that was not uncovered before, or just a bug in those libraries.

[brasko]

There really isn't enough info here to determine if this is a bug or not in cgdb

[oblitum]

@brasko I will explain where the issue lies, as I'm not familiar with the codebase, I'll defer producing a patch. This is an issue with cgdb.

What's happening here is that cgdb is in a tight loop.

Relevant backtrace:

* thread #1: tid = 0x1165b, 0x0000000100df77e6 cgdb`tgdb_recv_inferior_data(tgdb=0x00007fa599c03d40, buf=0x00007fa59a800000, n=4096) + 195 at tgdb.c:743, queue = 'com.apple.main-thread', stop reason = step over
  * frame #0: 0x0000000100df77e6 cgdb`tgdb_recv_inferior_data(tgdb=0x00007fa599c03d40, buf=0x00007fa59a800000, n=4096) + 195 at tgdb.c:743
    frame #1: 0x0000000100de9fff cgdb`child_input + 52 at cgdb.c:1268
    frame #2: 0x0000000100dea62d cgdb`main_loop + 1075 at cgdb.c:1448
    frame #3: 0x0000000100deb1c0 cgdb`main(argc=1, argv=0x00007fff5ee188b8) + 1075 at cgdb.c:1817

• The io_read inside tgdb_recv_inferior_data returns 0 (meaning EOF), but there's only a < 0 check, so the check fails and tgdb_recv_inferior_data returns 0.
• This makes child_input return 0 (meaning success) because it checks for -1 as error from tgdb_recv_inferior_data, but it has returned 0.
• In main_loop, child_input's return is checked for -1 as error to terminate the loop, but it has returned 0, which causes the continue statement to execute, creating a tight loop.

As a reference, there's another place in tgdb.c that checks io_read's return for < 0 and == 0.

Regarding the former backtrace of the issue, it was always the case because it is where this tight loop expends most of its time and hence the spot gets more chance of breaking into when attaching the debugger.

[brasko]

On Mon, Jul 21, 2014 at 02:39:28PM -0700, Francisco Lopes wrote:

@brasko I will explain where the issue lies, as I'm not experient with the codebase, I'll defer producing a patch, this is an issue with cgdb.

What's happening here is that cgdb is in an infinite loop.

Relevant backtrace:

* thread #1: tid = 0x1165b, 0x0000000100df77e6 cgdb`tgdb_recv_inferior_data(tgdb=0x00007fa599c03d40, buf=0x00007fa59a800000, n=4096) + 195 at tgdb.c:743, queue = 'com.apple.main-thread', stop reason = step over
  * frame #0: 0x0000000100df77e6 cgdb`tgdb_recv_inferior_data(tgdb=0x00007fa599c03d40, buf=0x00007fa59a800000, n=4096) + 195 at tgdb.c:743
    frame #1: 0x0000000100de9fff cgdb`child_input + 52 at cgdb.c:1268
    frame #2: 0x0000000100dea62d cgdb`main_loop + 1075 at cgdb.c:1448
    frame #3: 0x0000000100deb1c0 cgdb`main(argc=1, argv=0x00007fff5ee188b8) + 1075 at cgdb.c:1817

• The io_read inside tgdb_recv_inferior_data returns 0 (meaning EOF), but there's only a < 0 check, so the check fails and tgdb_recv_inferior_data returns 0.
• This makes child_input return 0 (meaning success) because it checks for -1 as error from tgdb_recv_inferior_data, but it has returned 0.
• In main_loop, child_input's return is checked for -1 as error to terminate the loop, but it returned 0, which causes the continue statement to execute, causing an infinite loop.

As a reference, there's another place in tgdb.c that checks io_read's return for < 0 and 0.

Regarding the former backtrace of the issue, it was always that one because it was where this infinite loop was expending most of its time and hence got more chance of breaking into when attaching the debugger.

Thanks for the information. I can't reproduce this, but I'm going to try
to improve this poorly written part of the code. I'll let you know in a
few days.

Thanks,
Bob Rossi

[oblitum]

@brasko ok thanks, I guess it could be reopened to avoid duplicates.

[mmueller]

Reproduced this on my own Mac running 10.9.4 and GDB 7.7 (homebrew). I'll see if I can make any progress on it.

[brasko]

On Mon, Jul 21, 2014 at 11:25:28PM -0700, Mike Mueller wrote:

Reproduced this on my own Mac running 10.9.4 and GDB 7.7 (homebrew). I'll see if I can make any progress on it.

Thanks Mike.

Francisco, I thought I should let you know that Mike and I are close to
a solution on this. He has a working CGDB, now we just need to improve
the patch to be commitable.

This should happen this week. I think perhaps CGDB will finally run
nicely on Mavericks.

Thanks,
Bob Rossi

[oblitum]

Ok, thank you guys.

[brasko]

On Tue, Jul 22, 2014 at 06:45:36PM -0700, Francisco Lopes wrote:

Ok, thank you guys.

I just pushed a fix. Try it out?

Thanks,
Bob Rossi

[oblitum]

@brasko @mmueller everything is fine now, regarding this issue, the only one left for me is that on OS X I'm unable to see the current selected line, or cursor, in the source window, which turns the tool almost unusable =/

[brasko]

On Wed, Jul 23, 2014 at 07:42:03PM -0700, Francisco Lopes wrote:

@brasko @mmueller everything is fine now, regarding this issue, the only one left for me is that on OS X I'm unable to see the current selected line, or cursor, in the source window, which turns the tool almost unusable =/

Glad we are getting somewhere finally.

Can you open a new issue and provide a screen shot?
(or perhaps a pastie can represent the issue?)

Thanks,
Bob Rossi

[mmueller]

[this is off-topic, but...]

@oblitum, you might be able to use :set as=highlight as a workaround, if the arrow isn't rendering for some reason.

[oblitum]

[yeah, off-topic...]

@mmueller, there's no problem with the arrow, it's the cursor which I can't see, so I have no feedback in which line I am so that I'm able to set a breakpoint.

[mmueller]

You can tweak the attributes of the selected line number in your ~/.cgdb/cgdbrc, for example:

hi SelectedLineNr ctermfg=green ctermbg=white

[mmueller]

We've heard a few times that the default style isn't very distinguishable for the currently selected line number. Opened #50 to address this.