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.