On Sat, Oct 25, 2014 at 3:54 AM, Stephan Witt <st.w...@gmx.net> wrote: > Am 25.10.2014 um 04:15 schrieb Scott Kostyshak <skost...@lyx.org>: > >> I don't know if it helps, but RStudio ran into the same bug and added >> workarounds in the following two commits: >> https://github.com/rstudio/rstudio/commit/9b286615e6f74ef8b738769fa1e3bb862461cbc6 >> https://github.com/rstudio/rstudio/commit/9effd13cb6cfe8bd79f0fa5e93e9b57488b3e186 > > Thank you for the pointers. Very interesting. > > The lesson is: they can fix it with small commits because they don't have > so many different places where fork()/exec() is used. LyX is different. > Additionally LyX has the concept of the PATH prefix. This will not work > with the "/bin/bash --login" trick. Though, I didn't tried it yet. > But is's a nice idea. > > At the moment I'm stuck in ForkedCall::generateChild(). I cannot get it > working. > The idea is to use execve() to pass a copy of the current environment. > Next I avoid the cmd_prefix_ trick to pass TEXINPUTS and do it per > environment. > To use execve() I have to mimick the PATH lookup like RStudio does. > > The modified code works on my system (pre-Yosemite) and fails on Yosemite. > Diagnosing the problem is very difficult - most operations are forbidden > between > fork and exec. E.g. I cannot see log messages of the forked LyX process in the > message pane. ForkedCall is unable to collect stdout/stderr of the child > process. > > I attach my changes for interested readers.
It looks like RStudio has now put in a better fix than the ones I linked to and says that we might want to take a look at it because it attacks the problem at the source. Can you see if the information is relevant for us? http://tex.stackexchange.com/questions/208181/why-did-my-tex-related-gui-program-stop-working-in-mac-os-x-yosemite/208182?noredirect=1#comment489284_208182 I paste the discussion below: We don't have to do this fixup before each fork/exec--we do it once in the GUI process itself, and then fork/exec, popen, NSTask, etc. all behave sanely for the rest of that process's lifetime. I'm happy to discuss more via email at j...@rstudio.com. And also we have a slightly better fix here (just uses posix APIs to mutate the environment instead of pointer manipulation directly on the char**). – Joe Cheng 7 hours ago @JoeCheng I wonder if the lyx environment is already set up and/or mutated by Qt before they call fork/exec? I didn't see where they remove duplicates in the link @scottkosty provided, but I'm not much of a C++ guy. My only concern with setting up a clean char **environ is that I don't trust Apple not to muck it up later, but I take a similar risk using NSProcessInfo. – Adam Maxwell 5 hours ago Oh and @scottkosty the fixes from our codebase in the message you linked, are all obsoleted now. The one I linked here is totally different, in that it attacks the problem at its source (fixing the parent's corrupted env table) rather than downstream when spawning children. Please, try to get your dev to take a look at this link, it's far superior than messing with environments at fork time and I would be very surprised if it didn't work for Lyx. – Joe Cheng 32 mins ago Scott
