The handle has not been destroyed until all references to it are removed even if saHandleDestroy is called. saHandleDestroy (called in finalize) just sets the state to PENDINGREMOVAL which means there may be no new references to the handle but current references are still valid until the refcount == 0. (Dispatch calls saHandlePut).
This only occurs once saHandlePut is called in saClmDispatch. As the code is currently, finalize should be checked within the Get/Put reference. saClmDispatch should return some kind of error if finalize is called. When the file descriptor is closed in saClmFinalize poll should return POLLNVAL and allow the finalize value to be verified. Send me a patch for the saftest and where you put the sleep and I'll look if this is a valid scenario. Regards -steve On Thu, 2007-10-25 at 15:27 -0700, Drew Moseley wrote: > 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 _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
