Xcode can't debug C++ program when configured to use Terminal instead of console

This is working for me. Specifically:

1. Using Xcode 27.0 on macOS 26.6.1, I created a new project from the macOS > Command Line Tool template, choosing C as the language.
2. I updated main.c to look like the code at the end of this reply.
3. In the scheme editor, I selected Terminal from the Console popup.
4. I ran the app, it opened Terminal, and I was able to interact with the program

… lots of stuff elided …
OSLOG-21DD5FFC-1D59-4DB9-B000-EB48DC9FE9F1 7 80 I 0 {version:2}	Initialization successful
Enter world type:
Cruel
Hello Cruel World
Process exited with status 0

Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.

[Process completed]

What version of macOS are you testing this on?

If you run through the above steps, do you see the same problem?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

#include <stdlib.h>
#include <stdio.h>
#include <stdbool.h>
#include <string.h>

int main(int argc, const char * argv[]) {
    printf("Enter world type:\n");
    char world[64];
    bool ok = fgets(world, sizeof(world), stdin);
    if (ok) {
        size_t len = strlen(world);
        ok = len > 0;
        if (ok) {
            char * last = world + len - 1;
            if (*last == '\n') {
                *last = 0;
            }
        }
    }
    if (!ok) {
        strlcpy(world, "Happy", sizeof(world));
    }
    printf("Hello %s World\n", world);
    return EXIT_SUCCESS;
}

Thanks for the reply, and I apologize for not providing more detailed information about the versions involved.

I'm on macOS 27.0 (26A428) on an M1 Mac mini. This behavior was seen on the released Xcode 27.0 (from the Mac App Store) and 27.1 beta downloaded from the Apple Developer web site.

The issue I've seen are on C++ projects that were created under earlier versions of Xcode and last built with Xcode 26 on macOS 26.

I created a new Command Line Tool project with the C++ language. I set the scheme for the build to run under Terminal.

main.cpp is the following sample C++ "hello world" program:

int main(int argc, const char * argv[]) {
   // insert code here...
   std::cout << "Hello, World!\n";
   return EXIT_SUCCESS;
}

Compile/build ran fine. Same issue occurred.

I also created another new project and selected the C language. I used your sample code as main.c. Same issue.

I just ran some additional tests. Both tests were run on clean macOS virtual machines (using UTM and the Virtualization Framework). No additional software installed other than the base OS.

I can confirm that Xcode 27 on macOS 26.6.2 works fine. Terminal comes up fine and the test program displays properly.

However, running the identical project (newly created, not copied) under Xcode 27 on macOS 27.0 fails with the same error. A possible regression for Xcode when running on macOS 27?

I can confirm that Xcode 27 on macOS 26.6.2 works fine.

OK. That’d explain why I didn’t see it.

After responding yesterday I asked about this issue internally. It seems that it’s a known thing. When Xcode runs a program in this way there’s a limit to the maximum line length. Hence the error you’re seeing, where --env=XYZ is being truncated to just --en.

Unfortunately I don’t see a good way to get back to exactly the behaviour you were used to. An easy, albeit hackish, alternative is to slightly tweak your code to connect stdio to a known pseudo TTY:

int fd0 = open("/dev/ttys001", O_RDONLY);
assert(fd0 >= 0);
int fd1 = open("/dev/ttys001", O_WRONLY);
assert(fd0 >= 0);
int fd2 = open("/dev/ttys001", O_WRONLY);
assert(fd0 >= 0);
dup2(fd0, STDIN_FILENO);
dup2(fd1, STDOUT_FILENO);
dup2(fd2, STDERR_FILENO);

You then have to wedge that Terminal window in a sleep call so that your program has full control over the TTY.

Still, it’s pretty ugly )-:

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

That is indeed ugly.

I submitted a bug report via Feedback Assistant as it’s clearly (at least to me) a regression in Xcode 27/macOS 27.

In the mean time I guess I’ll make due with Xcode’s console with standard input. :-(

I submitted a bug report via Feedback Assistant

Thanks. What was that bug number?

After zenning on this overnight I have a couple of other alternatives for you.

First, you can tweak your code to do something like this:

fprintf(stderr, "waiting for the debugger, pid: %d\n", getpid());
pause();

Then run your program from Terminal and, back in Xcode, choose Debug > Attach to Process > [your tool name]. The act of attaching generates a signal which breaks you out of the pause system call.

Alternatively, go to the Info tab of the scheme editor and select Launch > “Wait for the executable to be launch”. Then choose Product > Run and, in Terminal, run the tool.

Both of these options are less ugly, but also less convenient, than my previous suggestion.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks. What was that bug number?

Bug submitted via Feedback Assistant as FB24878563