Closed GoogleCodeExporter closed 9 years ago
I'm sorry, but I don't quite understand what the problem is. Can you try to
elaborate on how this bug manifests
itself and what you do to observe it? (Are you using Activity Monitor and more
and more Vim processes are
appearing, or what?)
Original comment by bjorn.winckler@gmail.com
on 1 Oct 2008 at 10:12
> (Are you using Activity Monitor and more and more Vim processes are
appearing, or
what?)
Exactly. This happens only when quickstart option is selected and when switching
directories in :Explore mode (this used to be called netrw, I believe)
Original comment by kon...@gmail.com
on 2 Oct 2008 at 7:36
That makes no sense at all....so does that mean you can start any number of Vim
processes just by switching
directories with netrw, or is there a limit?
It would be helpful if you could debug the problem by putting a breakpoint on
-[MMAppController
launchVimProcessWithArguments:]. That is where all new Vim processes are
spawned. Where is this function
called from?
Original comment by bjorn.winckler@gmail.com
on 2 Oct 2008 at 4:29
konryd: can you download snapshot 37 and let me know if these problems persist?
Thanks.
Original comment by bjorn.winckler@gmail.com
on 15 Nov 2008 at 6:58
I'm having the same issue as well where MacVim gets into some sort of fork loop
and keeps creating new
processes until I start seeing memoryfork errors from other applications. I
have to then killall Vim to and
relaunch. (But pretty much unusable.) I am not seeing this related specifically
to file explorer mode, but I haven't
narrowed it down to one thing yet.
I'm using a custom build off the current HEAD (id:
a02fc916573b09064141f942521ab096448c64ac).
My configure options are ./configure --enable-pythoninterp --enable-gui=macvim
Original comment by naitiks@gmail.com
on 17 Nov 2008 at 5:17
I downloaded snapshot 37 and the problem persists. I'm still looking for some
time to provide you with more
information, but my xcode skills are prety morbid, so it's going to be quite
hard for me.
In answer to your previous question: there doesn't seem to be a limit on the
number of processes spawned
(except for obvious resource limits).
Original comment by kon...@gmail.com
on 17 Nov 2008 at 9:25
I believe I'm having a similar issue. I'm seeing it on both my Mac Pro and my
Macbook. It came to my attention
when I began maxing out the sysctl limits for resource forks.
I used ps to determine which, something like "ps aux | grep MacVim | wc -l".
This number will continue to grow
until the max is reached. I've seen it as high as 300'sh.
Attached is the output of the errant processes in action. I've seen the same
behavior in both the latest stable,
and the latest snapshot as of 2008-11-30.
Original comment by kru...@gmail.com
on 1 Dec 2008 at 8:16
Attachments:
I uploaded a debug binary which logs more info to the console to here:
http://bjorn.winckler.googlepages.com/MacVim-081130.zip
Can you try running that and send me the log files? (You can cut&paste from
Console.app.)
By the way: that binary includes a patch which may even fix the problem you are
seeing...so pay extra
attention.
Thanks.
Original comment by bjorn.winckler@gmail.com
on 1 Dec 2008 at 8:55
Yhm... it's a shame to admit... but I couldn't find the way to see the logs you
mentioned (I opened it using "open
-W" command, but nothing got displayed; I imagine there's some obvious
knowledge I'm lacking).
O the other hand - this version actually fixed the problem. No vim processes
explosion happens. I'm amazed by
your debugging skills.
Original comment by kon...@gmail.com
on 3 Dec 2008 at 12:44
konryd: Open up Console.app (search in Spotlight, or go to
Applications->Utilities->Console) and you'll can see
all log files. From there you can copy&paste.
Original comment by bjorn.winckler@gmail.com
on 3 Dec 2008 at 12:51
Here it is. I moved up the directory tree several times and then down. Thanks
for the tip :)
Original comment by kon...@gmail.com
on 3 Dec 2008 at 1:43
Attachments:
Ok, this bug should be fixed now. I've pushed the patch to the public repo and
it will be in the next snapshot
(snap 40). I'll leave this issue open until the snapshot has been released.
Original comment by bjorn.winckler@gmail.com
on 3 Dec 2008 at 2:26
Original comment by bjorn.winckler@gmail.com
on 16 Jan 2009 at 9:46
Original issue reported on code.google.com by
kon...@gmail.com
on 1 Oct 2008 at 2:28