Take the 2-minute tour ×

I attached to a program with gdb in OSX and I want to use CFShow in the gdb console etc. However, nothing shows up. printf shows nothing as well:

(gdb) call (int) printf("Hello\n")
$10 = 6
(gdb) call (int) printf("Hello World!\n")
$11 = 13

Apple suggests the following tip for when attaching with gdb, to make the output appear in the gdb console:

(gdb) call (void) close(1)
(gdb) call (void) close(2)
(gdb) shell tty
(gdb) call (int) open("/dev/ttyp1", 2, 0)
$1 = 1
$2 = 2

In xcode's gdb console tty gives "not a tty", so I tried it in gdb in a terminal. There tty does work but after redirecting stdout there's still no output. Also no output if I direct stdout to a file.. :/

Any salvation?


On some programs (like TextMate) this method does work. The application I was trying to debug is /Developer/Applications/Audio/AU\ Lab.app. For some reason this trick does not work there.. Update: seems the real explanation is rather:

If after attaching I redirect stdout before calling printf for the first time, it works! If I first printf and only then redirect output, output shows up only after doing printf("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n") and then pressing enter (to repeat last command) 327 times.

So I guess redirecting stdout somehow makes libc confused and makes it use a buffer of 2**14 bytes for some reason?

share|improve this question
I cannot reproduce this problem. In the Debugger Console of XCode I have tried it with an Objective-C command line application using the Core Foundation framework; I have also run gdb in a Terminal on the same program. In both cases the call s work and return their output to the console. Could you create a new user account and try to give the steps to reproduce the issue from a clean install? –  user8472 May 30 '10 at 9:54
One more minor comment: According to the documention of CFType, the call to CFShow should put the output to stderr, not stdout. Of course, printf should still work after redirecting stdout somewhere else! –  user8472 May 30 '10 at 9:56
@user847: apparently this method does work for some applications and doesn't work for other(s). see my update. thanks! –  yairchu May 30 '10 at 21:34
I cannot reproduce this problem with /Developer/Applications/Audio/AU\ Lab.app either. In addition, the app is not compiled with debugging symbols enabled (switch -g ), so I can access neither the symbols nor the source code itself. If I run gdb on the program, the call (int) printf(...) command works fine for me, though. To be specific, the output will appear at the console just as it should. –  user8472 Jun 1 '10 at 8:58
@yairchu: Yes, at last I can reproduce the problem by manually redirecting output to a file (it always works on stdout for me, though)! The output is indeed buffered and the buffer is not flushed. If this happened in a regular program, I would use the call (int) fflush(stdout) command, but this does not seem to work in gdb - it always crashes. –  user8472 Jun 2 '10 at 9:30

1 Answer 1

up vote 1 down vote accepted

The problem could be related to a peculiarity of your setup. Here are a couple of further suggestions you could try to identify the source of the problem:

  1. First, check the way the debugger is launched - are you using the command line in the Terminal or is it through some GUI which may submit additional command line arguments beyond your control? (You mentioned XCode, but I don't see why you would debug the program you mentioned through XCode? And actually I am not sure how XCode executes gdb, so please try to stick to the terminal for now!)

  2. Do you have an init-file in your home directory (a file called .gdbinit or so) that configures gdb with some options you are unaware of? Here is a description of what gdb does on startup: http://sourceware.org/gdb/current/onlinedocs/gdb/Startup.html#Startup

  3. According to the manual page, using the -n option on startup will prevent loading any configuration files: http://sourceware.org/gdb/current/onlinedocs/gdb/Mode-Options.html#Mode-Options Does your problem still persist if you use this switch?

  4. One particular set of commands regards gdb's logging behavior: http://sourceware.org/gdb/current/onlinedocs/gdb/Logging-Output.html#Logging-Output Can you execute show logging at the console and check what happens to the output?

  5. What is the output of show inferior-tty? If it is set to "" then it will be the same as your gdb console (which is fine). Otherwise, program output will go somewhere else, but this cannot explain the issue you had with output disappearing form interactive gdb commands!

share|improve this answer
See new update. In short my own problem is solved now, but there's still a weird phenomenon here to be explained. The reason to debug "AU Lab" in xcode is to debug your Audio-Unit plugins which you can run with "AU Lab". Also I tried this on both my Snow-Leopard desktop and my Leopard laptop and both exhibit the same behavior. No .gdbinit and inferior-tty is "". thanks –  yairchu Jun 1 '10 at 21:21
Oh, I see. Thanks for the clarification, I had launched the application on the command line through gdb, not the way you have been doing; so that's why I could not reproduce the problem right away. –  user8472 Jun 2 '10 at 10:00
even though a mystery remains (as I've updated my question to reflect it), my original problem is solved. so I marked your answer as accepted –  yairchu Jun 3 '10 at 13:41

Your Answer


