poe@daimi.dk (Peter rb{k) (07/10/90)
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." * **************************************************************
rosenber@ra.abo.fi (Robin Rosenberg INF) (07/10/90)
!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.
It is even documented!, with a workaround reading like this
#include <exec/execbase.h>
...
AddSemaphore(s)
struct SignalSemaphore *s
{
InitSemaphore(s);
Forbid();
Enqueue(&SysBase->SemaphoreList,s);
Permit();
}
[...]
!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.
The (Lattice 5.05) #pragma for RemSemaphore was also incorrect. Apparently
the stub in Amiga.lib is correct since things worked when I removed the
<proto/exec.h> include. It should read:
#pragma syscall RemSemaphore 25e 801
(I think it was 25e 901)
!If asked (a lot) I might make some sort of patch...
Just encourage people to get the latest available docs. The RKM
Includes&Autodocs for 1.3 has been available for quite a while now.
-----------
Robin Rosenbergpoe@daimi.dk (Peter rb{k) (07/12/90)
rosenber@ra.abo.fi (Robin Rosenberg INF) writes: >!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. >It is even documented!, with a workaround reading like this Well, I don't have Includes & Autodocs 1.3, wish I had though! >#include <exec/execbase.h> >... >AddSemaphore(s) >struct SignalSemaphore *s >{ > InitSemaphore(s); > Forbid(); > Enqueue(&SysBase->SemaphoreList,s); > Permit(); >} Thanks, my workaround just doesn't add the semaphore to the list, that works fine also, FindSemaphore() ,of course, won't find it then. >[...] >The (Lattice 5.05) #pragma for RemSemaphore was also incorrect. Apparently >the stub in Amiga.lib is correct since things worked when I removed the ><proto/exec.h> include. It should read: > #pragma syscall RemSemaphore 25e 801 >(I think it was 25e 901) >Just encourage people to get the latest available docs. The RKM >Includes&Autodocs for 1.3 has been available for quite a while now. Ok! :-> >----------- >Robin Rosenberg - Peter (poe@daimi.dk) -- ************************************************************** * "Who other than IBM would want to put a mainframe on * * everybodys desk." * **************************************************************