This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Recent 4.1 breakage...
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.
Regards,
Loren