Recent 4.1 breakage...

[Howard Hinnant]

On May 18, 2006, at 12:01 PM, Loren James Rittle wrote:

> In article <FA39B51E-82A1-45CF-9756-4BBF64F220D8@apple.com>,
> Howard Hinnant<hhinnant@apple.com> writes:
>
>> On May 18, 2006, at 10:28 AM, Loren James Rittle wrote:
>>> That leave just one failure which has existed (for an unknown amount
>>> of time since I hadn't bootstrapped in ages):
>>>
>>> Assertion failed: (oss.str() == "Whatever"), function test01, file
>>> [...]
>>> libstdc++-v3/testsuite/27_io/basic_filebuf/seekoff/char/26777.cc,
>>> line 79.
>>> FAIL: 27_io/basic_filebuf/seekoff/char/26777.cc execution test
>
>>> Regarding the first point: what appears to have happened on my  
>>> machine
>>> is that some test (or multiple tests) obtains an semaphore from the
>>> system but doesn't always release it.  My machine is configured with
>>> 10 semaphores.  After running the test suite N times, they were
>>> exhausted.
>
>> It appears that if libstdc++-v3/testsuite/27_io/basic_filebuf/ 
>> seekoff/
>> char/26777.cc exits in this manner then it never calls s1.~semaphore
>> () and s2.~semaphore(), each of which would have called:
>
>>        semctl(sem_set_, 0, IPC_RMID, val);
>
>> If I'm understanding your point above, on your system if a process
>> terminates without releasing a semaphore, that semaphore is lost
>> forever?
>
> Howard,
>
> Yes, that is exactly what happened:
>
> S rittle@latour; ipcs -st
> Semaphores:
> T     ID     KEY        MODE       OWNER    GROUP    OTIME    CTIME
> S rittle@latour; ./a.out
> Assertion failed: (oss.str() == "Whatever"), function test01, [...]
> S rittle@latour; ipcs -st
> Semaphores:
> T     ID     KEY        MODE       OWNER    GROUP    OTIME    CTIME
> s 1048576          0 --rw-------   rittle    users 10:32:12 10:32:12
> s 983041          0 --rw-------   rittle    users 10:32:12 10:32:12
>
> However, the semaphore is not lost forever, it may be manually removed
> with ipcrm(1).  Might be a FreeBSD QoI issue.  OTOH, since semaphores
> span processes, it is probably working as intended.  I don't know  
> offhand.

Since:

2006-03-12  Howard Hinnant  <hhinnant@apple.com>

    * testsuite/27_io/basic_filebuf/underflow/char/10097.cc:
    Fix race condition.
    * testsuite/27_io/objects/char/9661-1.cc: Likewise.
    * testsuite/27_io/objects/wchar_t/9661-1.cc: Likewise.

increased the use of semaphores (by 1 in each of these tests), that  
explains why this change may have caused this type of failure to show  
up at a lower N test count.

-Howard