X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Message-ID: <4F3A14A8.4090506@acm.org> Date: Tue, 14 Feb 2012 00:00:40 -0800 From: David Rothenberger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: cygwin Subject: STC for libapr1 failure Content-Type: multipart/mixed; boundary="------------070103090706050305070306" X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com --------------070103090706050305070306 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The libapr1 test cases are failing again for flock locks. This same test case failed with 1.7.9 with a fatal error[1], but that was corrected. The test is no longer encountering the fatal error, but it is producing the wrong result. I extracted the attached STC to demonstrate the problem. It starts a number of child processes, each of which repeatedly grab and release a lock on a temporary file. While they have the lock, the increment a counter in shared memory in a racy way. If all goes well, the counter should end up having the value of CHILDREN * ITERS_PER_CHILDREN. And it does, sometimes. Other times, however, it's less than this value, indicating the lock did not work. (I'm using shmget for shared memory, so you have to have cygserver running. APR has a number of shared memory methods, including mmap, but this was the easiest for me to extract.) As before, I haven't been doing C programming in a while, so I'm not 100% sure the test case is valid, but it does demonstrate the same problem the APR test case is having. I've tried this on my Win7-64 box running the 20120210 snapshot and on a WinXP running stock 1.7.10. I get the same results in both places. Regards, David [1] http://cygwin.com/ml/cygwin/2011-08/msg00480.html -- David Rothenberger ---- daveroth AT acm DOT org I think we are in Rats' Alley where the dead men lost their bones. -- T.S. Eliot --------------070103090706050305070306 Content-Type: text/plain; name="stc-flock-fork.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="stc-flock-fork.c" /*********************************************************************** * This is a STC to show that flock occasionally does not work. * * It tries to use flock() for file locking. It creates a temporary * file, the uses fork to spawn a number of children. Each child opens * the file, then repeatedly uses flock to lock and unlock it. * * While each child has the lock, it increments a counter stored in * shared memory in a racy way, passing the current value to a function * which sleeps briefly, then returns the incremented counter. * * If all works correctly, the counter should end up be incremented * by each child iteration. * * However, this is failing for me occasionally. The counter ends up * being less than the expected value. * * This test was extracted from the APR test suite. * * Compile: gcc -Wall -o stc-flock-fork stc-flock-fork.c ***********************************************************************/ #include #include #include #include #include #include #include #include #include #include #include #define MAX_ITER 200 #define CHILDREN 6 #define MAX_COUNT (MAX_ITER * CHILDREN) /* Counter stored in shared memory. */ static volatile int *x; /* A temporary file used for flock. */ char tmpfilename[] = "/tmp/flocktstXXXXXX"; /* a slower more racy way to implement (*x)++ */ static int increment(int n) { usleep(1); return n+1; } /* Fork and use flock to lock and unlock the file repeatedly in the child. */ void make_child(int trylock, pid_t *pid) { if ((*pid = fork()) < 0) { perror("fork failed"); exit(1); } else if (*pid == 0) { int fd2 = open(tmpfilename, O_RDONLY); if (fd2 < 0) { perror("child open"); exit(1); } int rc; int i; for (i=0; i