Re: bug in sysv semaphores on -CURRENT
On Fri, 6 Sep 2002, Alfred Perlstein wrote:
Alfred (thanks) found a bug in my code. Sorry for the fuss folks :-(.
> * Michal Mertl <[EMAIL PROTECTED]> [020906 06:10] wrote:
> > There seems to be bug in $SUBJ. When I run attached program on recent
> > -CURRENT, it always (after several seconds) triggers the bug. I first
> > suspected a problem in the program's logic but on stable in runs just
> > fine.
> >
> > Esentially I use piece of shm memory to pass some data between several
> > processes. I implemented simple locking functions with semaphores and
> > noticed it behaves strange on -CURRENT and ok on -STABLE.
> >
> > CCing Alfred because he made some changes into the kernel part of $SUBJ. I
> > don't expect the bug is new though.
> >
> > May I ask someone with older -CURRENT to try running the program for a
> > minute?
>
> I found your bug.
>
> In the function ipc_unlock() you do this:
>
> > int
> > ipc_unlock(void)
> > {
> > struct sembufsem_buf;
> > int err;
> >
> > if (ipc_cfg->sem_owner != getpid()) {
> > fprintf(stderr, "%d: can't unlock (bug), owner: %d\n",
> > getpid(), ipc_cfg->sem_owner);
> > return (-1);
> > }
> > if (semctl(ipc_cfg->sem_id, 0, GETVAL) != 0) {
> > fprintf(stderr, "%d: can't unlock (bug), not locked\n",
> > getpid());
> > return (-1);
> > }
> > printf("%d: ipc_unlock()\n", getpid());
> > sem_buf.sem_num = 0;
> > sem_buf.sem_op = 1;
> > sem_buf.sem_flg = 0;
> > err = semop(ipc_cfg->sem_id, &sem_buf, 1);
> > if (err == -1) {
> > fprintf(stderr, "%d: semop()\n", getpid());
> > return (-1);
> > }
> > ipc_cfg->sem_owner = -1;
> > return (0);
> > }
>
> Problem is that you're messing with lock state after dropping your
> semaphore!
>
> If you move the
> ipc_cfg->sem_owner = -1;
> to before the semop() call it seems to fix things.
>
> -Alfred
>
--
Michal Mertl
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: bug in sysv semaphores on -CURRENT
* Michal Mertl <[EMAIL PROTECTED]> [020906 06:10] wrote:
> There seems to be bug in $SUBJ. When I run attached program on recent
> -CURRENT, it always (after several seconds) triggers the bug. I first
> suspected a problem in the program's logic but on stable in runs just
> fine.
>
> Esentially I use piece of shm memory to pass some data between several
> processes. I implemented simple locking functions with semaphores and
> noticed it behaves strange on -CURRENT and ok on -STABLE.
>
> CCing Alfred because he made some changes into the kernel part of $SUBJ. I
> don't expect the bug is new though.
>
> May I ask someone with older -CURRENT to try running the program for a
> minute?
I found your bug.
In the function ipc_unlock() you do this:
> int
> ipc_unlock(void)
> {
> struct sembufsem_buf;
> int err;
>
> if (ipc_cfg->sem_owner != getpid()) {
> fprintf(stderr, "%d: can't unlock (bug), owner: %d\n",
> getpid(), ipc_cfg->sem_owner);
> return (-1);
> }
> if (semctl(ipc_cfg->sem_id, 0, GETVAL) != 0) {
> fprintf(stderr, "%d: can't unlock (bug), not locked\n",
> getpid());
> return (-1);
> }
> printf("%d: ipc_unlock()\n", getpid());
> sem_buf.sem_num = 0;
> sem_buf.sem_op = 1;
> sem_buf.sem_flg = 0;
> err = semop(ipc_cfg->sem_id, &sem_buf, 1);
> if (err == -1) {
> fprintf(stderr, "%d: semop()\n", getpid());
> return (-1);
> }
> ipc_cfg->sem_owner = -1;
> return (0);
> }
Problem is that you're messing with lock state after dropping your
semaphore!
If you move the
ipc_cfg->sem_owner = -1;
to before the semop() call it seems to fix things.
-Alfred
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: bug in sysv semaphores on -CURRENT
* Michal Mertl <[EMAIL PROTECTED]> [020906 06:10] wrote: > There seems to be bug in $SUBJ. When I run attached program on recent > -CURRENT, it always (after several seconds) triggers the bug. I first > suspected a problem in the program's logic but on stable in runs just > fine. Can you tell me what I should be looking for? What seems to go wrong? Thanks for taking the time to provide a test case, I'll be looking into it shortly. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
