Recent 4.1 breakage...

[Paolo Carlini]

Loren James Rittle wrote:

>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.]
>  
>
Humpf, I'm sorry, in the meanwhile I was testing the below, and I would 
be rather happy with it ;) I'm simply putting to good use our VERIFY 
machinery (*finally*, some people would add, I'm sure). The patch is 
very safe, basically the tests themselves are unchanged, and could still 
be run with _GLIBCXX_ASSERT defined, in case of need. Is it fine with you?

>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?
>  
>
Not really, *on the spot*, sorry (it's late here in Italy...). But I 
want to understand what's going on. Can you print to cout the failing 
oss.str()? Is it empty or not? Out of curiosity, which is the value of 
BUFSIZ on FreeBSD?

Thanks for now,
Paolo.

//////////////////
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CL_semaphore_leak
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20060518/4c504496/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch_semaphore_leak
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20060518/4c504496/attachment-0001.ksh>