Hi,
I am tracking an issue in version 0.80.3 that appears to be a race
between aClmDispatch and saClmFinalize. I saw this problem first when
running the saftest program
AIS-clm-B.01.01/src/lifecycle/saClmDispatch/2-3.test.
That code runs two threads. subthread calls
saClmDispatch(..., SA_DISPATCH_BLOCKING);
The main thread works as follows:
saClmInitialize(...);
pthread_create(subthread);
wait on a semaphore set by the subthread indicating it has started.
saClmClusterNodeGetAsync(...);
saClmFinalize(...);
What appears to be happening is that the subthread is delayed for
some reason and the main thread processes all the way through the
finalize routine. Then the subthread calls saHandleInstanceGet()
at the beginning of saClmDispatch(). This function call returns
BAD_HANDLE which is expected since the library has been finalized.
If I use a semaphore in my test app to delay calling finalize until
the subthread finishes with saClmDispatch() the test app locks up
since saClmDispatch() does not return; it is called as BLOCKING
after all.
It is difficult to reproduce but if you add a sleep(4) call inside
the saClmDispatch() routine it happens frequently. The saClmDispatch
call appears to try and handle this by checking the
clmInstance->finalize variable however in this situation, the instance
has actually been freed by saHandleInstancePut() and is thus invalid.
Is this a valid testcase? Any idea on how best to fix this?
Drew
--
mailto:[EMAIL PROTECTED]
_______________________________________________
Openais mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/openais
