c - OpenGL window doesn't open in xcode (7.2) when run as a child process -

i on os x 10.10.5, , xcode 7.2. have program spawns child process run visualization using opengl/glut, i.e.

pid_t childpid; childpid = fork(); if(childpid == 0) { // child process   glutinit(&argc, argv);   ... } else{  // parent process else   ... } 

when run in xcode, program never returns glutinit. if instead use parent process visualization, , child run else, i.e.

if(childpid != 0) { // parent process   glutinit(&argc, argv);   ... } ... 

then opengl window pops up, , whole program runs fine. additionally, if run original version (with child doing visualization) when building makefiles in terminal outside of xcode, runs fine.

any ideas on cause this?

i haven't been able debug things far within xcode, because debugger follows parent process. if try attach child process through debug->attach process, error: "xcode couldn't attach “j2”. “j2” not support debuggable architecture." found questions on last issue of attaching other processes in xcode, solutions didn't work me.

you can't anything on child side of fork() other variety of exec() or _exit().

i'll quote leopard corefoundation framework release notes. don't know if they're still online, since apple tends replace rather extend core foundation release notes.

corefoundation , fork()

due behavior of fork(), corefoundation cannot used on child-side of fork(). if fork(), must follow exec*() call of sort, , should not use corefoundation apis within child, before exec*(). applies higher-level apis use corefoundation, , since cannot know higher-level apis doing, , whether using corefoundation apis, should not use higher-level apis either. includes use of daemon() function.

additionally, per posix, async-cancel-safe functions safe use on child side of fork(), use of lower-level libsystem/bsd/unix apis should kept minimum, , ideally async-cancel-safe functions.

this has been true, , there have been notes made of on various cocoa developer mailling lists in past. corefoundation taking stronger measures "enforce" limitation, thought worthwhile add release note call out well. message written stderr when uses api known not safe in corefoundation after fork(). if file descriptor 2 has been closed, however, no message or notice, bad. tried make processes terminate in recognizable way, , did while , handy, backwards binary compatibility prevented doing so.

in other words, has never been safe of on child side of fork() other exec new program.

besides general posix prohibition, oft-mentioned explanation is: a) pretty cocoa programs multithreaded these days, gcd , like. b) when fork(), calling thread survives child process; other threads vanish. since threads have been manipulating shared resources, child process can't rely on having sane state. example, malloc() implementation may have lock protect shared structures , lock have been held 1 of now-gone threads @ time of fork(). so, if remaining thread tries allocate memory, may hang indefinitely. other shared data structures may in corrupted state. etc.