Hi, jason napsal(a): > Hi Jan, > I haven't the patch you suggested(in order to catch it again). But I have > reproduced this issue and found something very strange for me: > > 1) corosync_dispath_get() got called by our CLM client after return form > polling the file descriptor of the IPC channel. But I don't think there is > any dispatch request generate from serverside because we have only one node > in cluster, no cluster membership change notification can happen. Are you polling on clm descriptor? If so, there is probably some dispatch request > > 2) the poll() in corosync_dispatch_get() returns 1 but the errno is not > zero, it is EINTR! Then it run into socket_recv(). Can poll really act > like this? Or the errno belongs to the previous syscall? I believe errno really belongs to previous call. Or, there is another possibility. Are you using signals in your application? If so, aren't you calling some syscals in them? > > 3) in socket_recv(), the call to recvmsg() returns -1 and errno is EBADF. > So after returns to corosync_dispatch_get() , the assertion raised. This is really weird. > On Dec 3, 2012 5:34 PM, "jason" <huzhijiang@xxxxxxxxx> wrote: > >> Thanks Jan, >> I will give it a try and find out the initial reason why this issue >> appear.in my environment. >> On Dec 3, 2012 5:12 PM, "Jan Friesse" <jfriesse@xxxxxxxxxx> wrote: >> >>> Hi, >>> honestly I'm really unsure why this assert is there. Actually, it really >>> looks like thing which shouldn't be there at all. I would suggest a >>> patch, which simply: >>> - remove whole #if defined (as it doesn't seem to be needed) >>> - remove assert >>> - check if error is CS_OK and if not, goto error_put >>> >>> Regards, >>> Honza >>> >>> jason napsal(a): >>>> Hi All, >>>> We have encountered an assertion at coroipc.c:925 and it seems hard to >>>> reproduce. According to the code of corosync-1.4.4 it means >>> socket_recv() >>>> did not return CS_OK as expected by coroipcc_dispatch_get(). But I >>> checked >>>> socket_recv() and found that it DO return CS_ERR_TRY_AGAIN or >>>> CS_ERR_LIBRARY in some cases. So does it really need this assertion or >>> do >>>> we need to deal with ! CS_OK cases at coroipc.c:925? >>>> >>>> Thank you! >>>> >>>> >>>> >>>> _______________________________________________ >>>> discuss mailing list >>>> discuss@xxxxxxxxxxxx >>>> http://lists.corosync.org/mailman/listinfo/discuss >>>> >>> >>> > _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
