Problem with MacVim and latex-suite

[Nikola Knežević]

Hi,

I recently switched to pathogen-style configuration, which meant updating latex-suite, and my configuration files. Now, I'm having problem with MacVim in GUI mode (command line version of vim works without problems).

Whenever I try to open .tex file from command line ('mvim paper.tex'), MacVim window opens, completely empty. It seems as it hangs, but there is no increased CPU usage. I can kill the application with Cmd+Q, but Vim process remains in memory:

$ ps aux|grep Vim
knezevic 6481 0.4 0.8 2632732 16380 p0 Ss+ 1:09AM 0:01.55 /Users/knezevic/Applications/MacVim.app/Contents/MacOS/Vim -f -g paper.tex

If I start mvim without any configuration, all is fine. If I skip just .vimrc, again, all is fine.

I traced the problem down to the combination of VCScommand and Latex-Suite. The problem occurs whenever this line is present, and I'm opening .tex file from command line:
let VCSCommandEnableBufferSetup=1

Then, I see this process lingering around:
/bin/zsh -c ('git' rev-parse --is-inside-work-tree) >/var/folders/aZ/aZYa0SaaGy0cuabgeZbImU+-6cg/-Tmp-/vNVlVet/3 2>&1

The last test I tried is to open file directly from the command line, but from some other git repository. When I try to open README.txt from macvim's repository, all is fine. When I copy my *.tex files to macvim's repository, and try to open them, it hangs the usual way (empty window, doesn't accept input, no increased CPU usage).

Has anyone experienced something similar? I'm using the latest versions of MacVim, Latex-suite and VCSCommand.

Best,
Nikola

[björn]

2010/8/12 Nikola Knežević :

This looks like the same problem as [1] (you are using zsh, right?).
You should be able to work around it by passing the "-f" flag (please
confirm), or by not using zsh. (No, I don't think they are viable
alternatives, but it's all I have at the moment.)

I debugged the problem and found that it is caused by calling setsid()
when forking but have no idea why this is [2]. It is called from
macos_fork() inside src/os_macosx.m in case you feel like debugging
the issue. I'd appreciate the help -- I'm not getting anywhere with
it.

Björn

[1] http://code.google.com/p/macvim/issues/detail?id=271
[2] http://groups.google.com/group/vim_mac/browse_thread/thread/f1b13ba4b11c6eb7

[Nikola Knezevic]

On Aug 12, 12:24 pm, björn <bjorn.winck...@gmail.com> wrote:
> > I traced the problem down to the combination of VCScommand and Latex-Suite. The problem occurs whenever this line is present, and I'm opening .tex file from command line:
> > let VCSCommandEnableBufferSetup=1
>
> > Then, I see this process lingering around:
> > /bin/zsh -c ('git' rev-parse --is-inside-work-tree) >/var/folders/aZ/aZYa0SaaGy0cuabgeZbImU+-6cg/-Tmp-/vNVlVet/3 2>&1
>

> This looks like the same problem as [1] (you are using zsh, right?).
> You should be able to work around it by passing the "-f" flag (please
> confirm), or by not using zsh.  (No, I don't think they are viable
> alternatives, but it's all I have at the moment.)

Hi Bjorn,

for some weird reason, I'm not getting messages on my email, so I have
to use webmail. But that is another story :)

Thanks for the pointers. Indeed, if I use -f flag, it all works
beautifully.

> I debugged the problem and found that it is caused by calling setsid()
> when forking but have no idea why this is [2].  It is called from
> macos_fork() inside src/os_macosx.m in case you feel like debugging
> the issue.  I'd appreciate the help -- I'm not getting anywhere with
> it.

I'll try to have a look at it next week. I'm not experienced with
ObjC, but syscalls are syscalls :)

Best,
Nikola

[Nikola Knezevic]

On Aug 12, 3:51 pm, Nikola Knezevic <laladelausa...@gmail.com> wrote:
> > I debugged the problem and found that it is caused by calling setsid()
> > when forking but have no idea why this is [2].  It is called from
> > macos_fork() inside src/os_macosx.m in case you feel like debugging
> > the issue.  I'd appreciate the help -- I'm not getting anywhere with
> > it.

I took a look at the code. I can't figure out why the problem occurs,
but I solved it by using double-fork(). This way, I ensure that MacVim
process becomes a child of init. Double fork()-ing is often used when
you want to make sure that the child doesn't inherit anything from the
parent.

Here is the patch I used, let me know if it works for you:
<http://lpd.epfl.ch/knezevic/setsid.patch>

Best,
Nikola

[björn]

Thanks. I'll take a look at it but not before the 7.3 release...we've
had some severe fork-related problems in the past so I don't dare to
include this without some testing first.

I don't at all understand these forking issues (indeed I don't
understand why we can't just leave out the setsid() call since this
also gets rid of the problem). Does double-forking have any obvious
negative side effects?

Björn

[Nikola Knezevic]

On Aug 15, 8:54 pm, björn <bjorn.winck...@gmail.com> wrote:
> > I took a look at the code. I can't figure out why the problem occurs,
> > but I solved it by using double-fork(). This way, I ensure that MacVim
> > process becomes a child of init. Double fork()-ing is often used when
> > you want to make sure that the child doesn't inherit anything from the
> > parent.
>
> > Here is the patch I used, let me know if it works for you:
> > <http://lpd.epfl.ch/knezevic/setsid.patch>
>
> Thanks.  I'll take a look at it but not before the 7.3 release...we've
> had some severe fork-related problems in the past so I don't dare to
> include this without some testing first.

That sound ok :)

> I don't at all understand these forking issues (indeed I don't
> understand why we can't just leave out the setsid() call since this
> also gets rid of the problem).  Does double-forking have any obvious
> negative side effects?

There are no negative side effects of doing double forking. It is a
useful technique when you want to make sure the process doesn't have
controlling terminal, and to fight off zombies the easy way (init will
reap them).

Can you explain me what is the intention of macos_fork()? What do you
want to achieve? I'm trying to understand the intention, to see
whether setsid is really important.

[björn]

On 15 August 2010 21:32, Nikola Knezevic wrote:

Ahem, well, gvim traditionally forks by default and hence MacVim forks
as well...that's pretty much all that I know. Nico Weber wrote that
code so he may have a better answer (if he's still reading this
list?). Sorry, I can't give you a better answer than this but it is
beyond my current understanding.

Björn

[björn]

I've merged this patch now. Let's be on the look out to see if it
causes any problems.

Björn