Hangs on 'quit', under OSX10.8 about cgdb HOT 12 CLOSED

Thanks for reporting. Let me know if you get a stack trace - I don't have access to a MacOS machine at the moment to test this.

from cgdb.

Apologies for the late response, I've only just gotten back to this.

Backtrace (as reported by GDB) is just this:

#0 0x00007fff8f7da322 in select$DARWIN_EXTSN ()
#1 0x000000010b91f5c4 in main_loop inlined at /Users/trevor/src/cgdb/cgdb/cgdb.c:1329

Specifically, that's this bit of code in cgdb.c:

1328 /* Wait for input */
1329 if (select(max + 1, &rset, NULL, NULL, NULL) == -1) {

Some brief debugging shows that after a program finishes running and I give cgdb a "quit" command, it never reaches the cleanup() function. If I've not run any program, though, it takes the "quit" input and shuts down as one would expect it to. I haven't yet tracked it down far enough to figure out precisely why it's not reaching cleanup().

Here's a text dump from running "ls" through cgdb, and then trying to quit:

(gdb) file ls
Reading symbols for shared libraries .... done
Reading symbols from /bin/ls...done.
(gdb) run
Starting program: /bin/ls
Reading symbols for shared libraries +++.............................. done
Doxyfile cgdb.h command_lexer.l highlight.o logo.c sources.h
Makefile cgdb.o command_lexer.o highlight_groups.c logo.h sources.o
Makefile.am cgdbrc.c filedlg.c highlight_groups.h logo.o tags
Makefile.in cgdbrc.h filedlg.h highlight_groups.o scroller.c tester.c
TODO cgdbrc.o filedlg.o interface.c scroller.h usage.c
[31mcgdb[39;49m[0m command_lexer.c highlight.c interface.h scroller.o usage.h
cgdb.c command_lexer.h highlight.h interface.o sources.c usage.o

Program exited normally.
(gdb) quit

<and then we hang forever here, with that blank line at the bottom of the screen, until I kill the process>

I'm going to continue to poke with this for a bit.. see if I can't track it down further.

from cgdb.

More data:

When an executable has been loaded, we never get into tgdb_add_quit_command() at all.

In tgdb_process(), io_read() normally immediately returns 0 bytes when I issue a 'quit' command (which tgdb_process() interprets as an EOF and thus triggers cgdb to quit). If I've run any program within cgdb before giving that 'quit' command, though, I'm instead receiving seventeen bytes from io_read(), instead of zero. Those seventeen bytes are: "\r\n\032\032post-prompt\r\n", which sends us over into the handle_post_prompt() handler instead, and then no more data is received from gdb, so we sit in the main loop's "select()" function forever, and cgdb never exits.

(Those bytes appear to be consistent, no matter what program I've run within cgdb)

Any clue at this point? I'm kind of at the limit of my knowledge of the inner workings of cgdb/gdb.

from cgdb.

Issue is still present with the just-released Xcode 4.5, which ships with a new version of gdb:

GNU gdb 6.3.50-20050815 (Apple version gdb-1822) (Sun Aug 5 03:00:42 UTC 2012)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin".

from cgdb.

Further notes: After giving the "quit" command to gdb, the gdb process becomes a zombie process.

I can still quit CGDB cleanly by hitting escape, and giving the :q command to quit from the CGDB side; the problem is definitely just that cgdb isn't noticing that gdb has gone into a zombie state, when I attempt to give the quit command from that side.

from cgdb.

This is fixed by a patch merged in #5. Thanks for your patience and the additional debugging information here.

from cgdb.

Hi,

I think I may still be getting the same issue as the original poster.

For example, if I start a debugging session, set a breakpoint, run until I hit the breakpoint, and then issue the quit command to gdb, the gdb session will get stuck - at least, until I press [esc] and issue :quit to cgdb, at which point the session will exit as expected.

However, if I repeat the above steps but do not issue a run command, the gdb quit command will work as expected.

Version info:

$ cgdb --version
CGDB 0.6.7

$ gdb --version
GNU gdb (GDB) 7.7

OSX version: 10.9.3

(gdb and cgdb built/installed via the homebrew package manager.)

Thanks,

from cgdb.

For what it's worth, cgdb is still quitting successfully for me, with CGDB 0.6.7 and GNU gdb 6.3.50-20050815 (Apple version gdb-1824) (Wed Feb 6 22:51:23 UTC 2013).

I have not tried with a homebrew-built version of gdb, but I imagine that the issue will be somewhere in the interaction between cgdb and that newer build of gdb.

from cgdb.

Hi vectorstorm, that's interesting to hear, and I think you may be onto something regarding the cause of the issue.

Out of interest, I presume you're on an older version of OSX? Because the only reason I built my own gdb (well, had homebrew build it for me) was because I was under the impression that Apple had stopped distributing their own build of it with newer versions of OSX...?

Thanks for the reply,

from cgdb.

Actually, I'm on latest Mavericks. You're correct that gdb isn't shipped by Apple any more, and installing the official Xcode command-line tools package no longer gives you gdb. I presume that my copy of Apple-branded gdb has been left behind from an old Xcode command-line utilities package from an earlier revision of the OS.

from cgdb.

I thought I should let you know that this is the same as issue #5 and #46 and I'm fixing this issue correctly. The commit should happen soon.

from cgdb.

On Mon, May 26, 2014 at 04:45:41PM -0700, vectorstorm wrote:

Actually, I'm on latest Mavericks. You're correct that gdb isn't shipped by Apple any more, and installing the official Xcode command-line tools package no longer gives you gdb. I presume that my copy of Apple-branded gdb has been left behind from an old Xcode command-line utilities package from an earlier revision of the OS.

I finally fixed this upstream. Sorry for the delay.

Bob Rossi

from cgdb.