Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mit-eddie!bloom-beacon!eru!luth!sunic!dkuug!daimi!poe
From: poe@daimi.dk (Peter rb{k)
Newsgroups: comp.sys.amiga.tech
Subject: Bug in AddSemaphore()!
Keywords: semaphores,exec
Message-ID: <1990Jul9.185240.8666@daimi.dk>
Date: 9 Jul 90 18:52:40 GMT
Sender: news@daimi.dk
Organization: DAIMI: Computer Science Department, Aarhus University, Denmark
Lines: 37

This may already be widely known, but here it is:

I think, that I have found a bug in the AddSemaphore() routine in
exec.library.

As far as I know, AddSemaphore() is supposed to add a SignalSemaphore into
the system list of such structures.

While trying to track down a spurious bug in the project that I am currently 
working on, I looked into the code for RemSemaphore() because the .fd files
that I have indicate, that RemSemaphore() should have its argument in A0,
(this is a heavy assembler-addict writing! :-> ), while all other Rem-routines
have their pointer in A1 for easy use with Remove(). And right enough, the
ROM code expects the pointer in A1. So the .fd file was incorrect in one 
place, maybe it was with AddSemaphore() too.

When I looked at the code for AddSemaphore() I discovered, that the argument
IS expected in A0, and that AddSemaphore() does an InitSemaphore() first,
but whoever wrote this routine forgot, that InitSemaphore() does NOT make
A1 point to the SignalSemaphore. So when Enqueue() is called for the semaphore
A1 is wrong, and strange things happen!

When I removed all the AddSemaphore() / RemSemaphore() calls from my code,
the bug disappeared.

All of this is concerning an A500 with 1MB, and Version tells me, that the
KickStart is 33.180

If asked (a lot) I might make some sort of patch...

 - Peter (poe@daimi.dk)

--
**************************************************************
* "Who other than IBM would want to put a mainframe on       *
*  everybodys desk."                                         *
**************************************************************