-
Notifications
You must be signed in to change notification settings - Fork 179
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hangs on 'quit', under OSX10.8 #1
Comments
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. |
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 () Specifically, that's this bit of code in cgdb.c: 1328 /* Wait for input */ 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 Program exited normally. <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. |
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. |
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) |
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. |
This is fixed by a patch merged in #5. Thanks for your patience and the additional debugging information here. |
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, However, if I repeat the above steps but do not issue a Version info:
OSX version: 10.9.3 (gdb and cgdb built/installed via the Thanks, |
For what it's worth, cgdb is still quitting successfully for me, with 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. |
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, |
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. |
On Mon, May 26, 2014 at 04:45:41PM -0700, vectorstorm wrote:
I finally fixed this upstream. Sorry for the delay. Bob Rossi |
Using cgdb release 0.6.6, built using homebrew (http://mxcl.github.com/homebrew/).
Verified on two different OSX10.8/Xcode4.4 machines that after any debugging session of any executable, when the "quit" command is given, cgdb hangs and must be explicitly killed. It appears to work normally in all other ways.
If no executable is actually run, cgdb exits successfully when the "quit" command is given.
Attaching gdb to a hung cgdb process suggests that the hang is happening within a call to "select()" (although my cgdb is built without debugging symbols; my next step is going to be to rebuild cgdb manually, complete with debug symbols, and see if I can't get a proper stack trace for where the hang is happening)
Works correctly for me under OSX 10.7 and earlier.
gdb version:
GNU gdb 6.3.50-20050815 (Apple version gdb-1820) (Sat Jun 16 02:40:11 UTC 2012)
cgdb version:
CGDB 0.6.6
Copyright 2002-2010 Bob Rossi and Mike Mueller.
The text was updated successfully, but these errors were encountered: