Re: STC for libapr1 failure

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Feb 15 14:14, David Rothenberger wrote:
> On 2/15/2012 1:20 PM, Corinna Vinschen wrote:
> > On Feb 15 13:15, David Rothenberger wrote:
> >> On 2/15/2012 12:45 PM, Corinna Vinschen wrote:
> >>> On Feb 15 11:39, David Rothenberger wrote:
> >>>> But... now one of the flock tests is failing. It takes a while to
> >>>> extract a STC from the APR test suite because everything is written in
> >>>> APR-ese and I have to convert every APR call into the base C library
> >>>> calls. I'll work on that over the next day or three.
> >>>>
> >>>> The gist of the test that's failing is this:
> >>>>
> >>>>  * Create a file.
> >>>>  * Get an exclusive flock on it.
> >>>>  * Spawn a child process that attempts to get an exclusive, non-blocking
> >>>>    lock on the file.
> >>>>
> >>>> The test is expecting that the child will not be able to get the lock,
> >>>> but the child is able to.
> >>>[...]
> >>> Does it fork/exec or does it only exec? 
> >>
> >> Looks like fork/exec. execv to be precise.
> >>
> >>> I guess I really need the testcase.
> >> [...]

I read the Linux man page again (http://linux.die.net/man/2/flock)
and I just hacked the following testcase, based on your flock STC.

It creates a lock in the parent, then forks a child.  The child tries to
grab the lock, first using the inherited file descriptor.  This is
supposed to work.  Then it opens the file again and tries to lock the
file using that descriptor.  This is supposed to fail with EWOULDBLOCK.
If it failed to lock the file one way or the other, it tries to unlock
the file using the second descriptor.  In theory this should fail.  If
it doesn't fail, it tries to lock the file again using both descriptors.
The expected result is the same as in the first two tries.  Eventually
the child exec's, and runs the entire set of tests again.  The result
should be the same as for the forked child.

I tried this test on both, Linux and Cygwin (latest from CVS), and it
behaves identically:

Linux$ ./stc-flock-forkexec
funlock from forked child with new descriptor succeeded but shouldn't
funlock from execed child with new descriptor succeeded but shouldn't

Cygwin$ ./stc-flock-forkexec
funlock from forked child with new descriptor succeeded but shouldn't
funlock from execed child with new descriptor succeeded but shouldn't

Funny enough, unlocking always returns success on the descriptor not
holding the lock, even on Linux.  But the second set of tests shows that
the lock is still firm in the hands of the first descriptor.

The testcase is attached.  I'm pretty curious what your test is actually
testing.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Attachment: stc-flock-forkexec.c
Description: Text document

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple