Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Message-ID: <3BE65E36.DB54A35B@syntrex.com>
Date: Mon, 05 Nov 2001 10:39:02 +0100
From: Pavel Tsekov <ptsekov AT syntrex DOT com>
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: 1.3.3 (20011018): fork() and VIM problem
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello, there :)

I just want to report something I've encountered last night
while I was examining setup.exe source code with VIM. I
tried to find out all the reference to the 'package' global
variable using the following VIM command:

:grep -n package *.cc

The VIM current working dir was:
/usr/src/cygwin-snapshot-20011018/winsup/cinstall

I pressed enter to launch the command and the console I was
running VIM got stuck i.e. no response from the grep, no ctrl-c,
no nothing :). I got interested and tried the same command again
and again and all of my tries ended up with a unresponsive console.
So at this point I build debug VIM and fired gdb (I had a cygwin1.dll
with symbols installed - its from the 20011018 snapshot). Tracing the
ex_make function in quickfix.c of the VIM source showed me how VIM
builds the grep command line:

before the fork() call the line looks like this:
/bin/bash -c grep -n -n package *.cc /dev/null 2>&1| tee
/tmp/tmp_vim_dir_here/a_file_in_it

Then cygwin forks and I'm at my breakpoint at os_unix.c which wait()s
in a loop for my pipeline to exit - however I'm stuck. Typing ps
from another console I see bash and tee - obviously grep has exited. So
killing the `tee` with signal 9 I am again into GDB and after the
wait().
However typing `continue` i still got vim stuck - so I have to salute
him
with the 9 signal too.

Ok, now I decided to use the CYGWIN_FORK_SLEPP varibale and set it to
20000.
Launch vim (standalone without gdb) see how of the three processes are
forked
and automagically the the command gets executed and prints the output of
grep
then goes back to vim.

Then I tried to do the FORKDEBUG trick - I worked fine launched my .cmd
file
and in gdb I set breakpoints into the child at os_unix.c where the child
after
fork is handled and at the execvp - again I step forth and back and no
error 
of anykind at all ... the command executes, output is printed and vim
returns
fine.

At last I tried strace but with no luck - everything is fine.

So I tried again just with plain VIM no debuggin or tracing  tricks and
the
problems happens again - VIM is stuck. I've tried the same command in
the VIM
source directory /usr/src/vim-6.0.11-1/src  - :grep -n package *.c - and
this
worked finding 2 or 3 result I dont remember exactly - however changing
the
command to :grep -n for *.c got the console locked again.

So I think there is some kind of problem with fork syncing the
parents/childs
but since I'm not an expert at this point I can just report the problem
since
none of my approaches did work well :)  It looks like slowing down the
execution
- invoking debuggers from fork code, strace-ing and techniques like this
hide
the actual problem, however it seems also that the problem is triggered
by some
kind of timing issues.

Things I still havent tried but will try too:

1. To attach to the first child (bash) as it is sleeping if
   CYGWIN_FORK_SLEEP is enabled.

2. Changeing execvp so that it will unset FORKDEBUG after
   the execution of the first child (bash) so that no second
   and third gdb windows appear at all.

3. Changeing the /bin/bash to /bin/sh

4. Upgrading to more recent snapshot of cygwin1.dll

5. Any other techniques you would suggest

Again I want to say this is 99 % reproducable on my system
and I'd like to know if anyone experinces the same on
theirs.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/