Re: Recent 4.1 breakage...

[Loren James Rittle <rittle at latour dot labs dot mot dot com>]

In article <200605181644.k4IGiUaC050865@latour.labs.mot.com>,
Loren James Rittle <rittle@latour.labs.mot.com> writes:

> I think all tests using SysV IPC need to be stuctured so that
> the main process starts N children to conduct the test.  The main
> process is written so that abort is never called and it may
> always cleanup the semaphore.  Appears to affect only a small set
> of tests.

Here is my proposed patch to address the semaphore leak issue only:

	* testsuite/27_io/basic_filebuf/seekoff/char/26777.cc (test01):
	Restructure so that no VERIFY check is ever made by the initial
	process while a semaphore lives.  Report child VERIFY check
	failure.

[I think that this code was and is still buggy since if
 VERIFY( fbout.is_open() ) ever fails, then a deadlock would occur.]

Index: libstdc++-v3/testsuite/27_io/basic_filebuf/seekoff/char/26777.cc
===================================================================
--- libstdc++-v3/testsuite/27_io/basic_filebuf/seekoff/char/26777.cc	(revision 113891)
+++ libstdc++-v3/testsuite/27_io/basic_filebuf/seekoff/char/26777.cc	(working copy)
@@ -29,6 +29,7 @@
 #include <fcntl.h>
 #include <sys/types.h>
 #include <sys/stat.h>
+#include <sys/wait.h>
 
 // libstdc++/26777
 void test01()
@@ -44,39 +45,61 @@
 
   unlink(name);  
   mkfifo(name, S_IRWXU);
-  semaphore s1, s2;
 
-  int child = fork();
-  VERIFY( child != -1 );
+  int child1, child2;
+  int status1, status2;
 
-  if (child == 0)
-    {
-      filebuf fbout;
-      fbout.open(name, ios_base::in | ios_base::out);
-      VERIFY( fbout.is_open() );
-      fbout.sputn("Whatever", 8);
-      fbout.pubsync();
-      s1.signal();
-      s2.wait();
-      fbout.close();
-      s1.signal();
-      exit(0);
-    }
+  {
+    semaphore s1, s2;
 
-  filebuf fbin;
-  fbin.open(name, ios::in);
-  s1.wait();
+    child1 = fork();
 
-  fbin.sgetc();
-  fbin.pubseekoff(0, ios::cur, ios::in);
-  s2.signal();
-  s1.wait();
+    if (child1 == 0)
+      {
+	filebuf fbout;
+	fbout.open(name, ios_base::in | ios_base::out);
+	VERIFY( fbout.is_open() );
+	fbout.sputn("Whatever", 8);
+	fbout.pubsync();
+	s1.signal();
+	s2.wait();
+	fbout.close();
+	s1.signal();
+	exit(0);
+      }
 
-  ostringstream oss;
-  oss << &fbin;
-  fbin.close();
+    child2 = fork();
 
-  VERIFY( oss.str() == "Whatever" );
+    if (child2 == 0)
+      {
+	filebuf fbin;
+	fbin.open(name, ios::in);
+	s1.wait();
+
+	fbin.sgetc();
+	fbin.pubseekoff(0, ios::cur, ios::in);
+	s2.signal();
+	s1.wait();
+
+	ostringstream oss;
+	oss << &fbin;
+	fbin.close();
+
+	VERIFY( oss.str() == "Whatever" );
+
+	exit(0);
+      }
+
+    if (child1 != -1)
+      wait(&status1);
+    if (child2 != -1)
+      wait(&status2);
+  }
+
+  VERIFY( child1 != -1 );
+  VERIFY( child2 != -1 );
+  VERIFY( WIFEXITED(status1) );
+  VERIFY( WIFEXITED(status2) );
 }
 
 int main()

> PPS, >Anyway, remains to explain why 26777 is failing in the first place on 
>> FreeBSD. Without hints I have no idea, sorry.

> Agreed, I will work on that now that we know why I saw semaphore
> usage failure. ;-)

Well, I'm confused on the expected behavior of 26777 (even after
reading the PR) and exactly what I see on FreeBSD 5.  Here is the read
on the fifo and the lseek from a truss log:

82979: read(0x3,0x804d000,0x3ff)                 = 8 (0x8)
82979: lseek(3,0xfffffffffffffff8,SEEK_CUR)      = 0 (0x0)

Paolo, make any sense to you?

Regards,
Loren