On Nov 19 16:04, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: > Hi, > > As I previously reported, there is a weird behavior of CYGWIN implementation > of SYSV semaphores, and a bug exposition for one problem is attached below > (I'm still looking into some other issues in there). > > If the code is compiled with both BUG1 and BUG2 defined (as shown), it > will abort at iteration 16384 (just the default semaphore overflow). > > Undefining BUG2 causes the problem disappear (because there is no longer > UNDO on the 1st semaphore). Also, running the code with just one semaphore > (undef BUG1) causes no problem. Finally, replacing "#if 1" with "#if 0" > to unlock the semaphore allows to run indefinitely with any combination of > BUG1/2 (just remember to issue ipcs/ipcrm to start with a clean slate at > all times). > > Reviewing the code of CYGSERVER, there is an apparent bug in the > semundo_clear() > routine (at around line 536, which looks like "i++, sunptr++;", and advances > both undo indexes even when "if (sunptr->un_id == semid)" (line 524) > failed to match semid. This means that for two (or more) semaphores, the > undo index "i" moves ahead even when nothing was done while still searching. > This causes the adjust pointer to miss the position to clear, and overflow > the semaphore adjust value (line 1207, semop(), by the virtue of > semundo_adjust()'s logic at about line 486).
This is original FreeBSD code, so I have a hard time to follow the idea that it might be wrong. I stared a long while into the source now, and I compared that with the latest version of the upstream code. The i counter is in lockstep with the sunptr pointer. The only time something happens is if sunptr->un_num (== suptr->un_ent[i].un_num) equals semnum. In that case, suptr->un_ent[i] is overwritten with with the last element uptr->un_ent[suptr->un_cnt], and then the code calls continue, thus NOT incrementing i and sunptr. So the same element, now containing the contents of suptr->un_ent[suptr->un_cnt], is evaluated again. Am I missing something? Incidentally this seems to be wrong now in the new upstream code, which uses for rather than while, thus i and sunptr are actually incremented in the above case, too. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple