[M3devel] CM3 d5.5.0 CVSup client issues.

John Polstra jdp at polstra.com
Thu Aug 23 06:04:44 CEST 2007


Alex Bochannek wrote:
> Tony Hosking <hosking at cs.purdue.edu> writes:
>> The rest of your errors indicate something is terribly wrong with the
>> threading subsystem.
>>
>>>   ***
>>>   *** runtime error:
>>>   ***    Thread client error: Acquire of mutex already locked by self
>>>   ***    file "ThreadPThread.m3", line 112
>>>   ***
>> This is a sanity check to make sure mutexes are not double-acquired.
> 
> I suspect a race condition somewhere since it's not easily reproducible.

Not many race conditions are possible in CVSup.  It's multi-threaded, 
but the threads basically don't interact with each other and don't 
require locking against each other.  It's more like a pipeline, with one 
thread feeding another thread, but virtually no interaction between 
threads otherwise.

> 
>> One question: did you completely rebuild all the libraries?
> 
> As far as I know. I'd be happy to do it again though.
> 
>>>   *** runtime error:
>>>   ***    <*ASSERT*> failed.
>>>   ***    file "../src/FileStatus.m3", line 505
>>>   ***
>> Where is this module?
> 
> CVSup code in the suplib library. The relevant procedure starts out like
> this:
> 
> PROCEDURE WrPut(ww: WrWriter; fs: T)
>   RAISES {Error, Thread.Alerted, Wr.Failure} =
>   VAR
>     pcType: PathComp.Type;
>     pcName: TEXT;
>     dirUpAttr: FileAttr.T;
>   BEGIN
>     IF ww.cannotWrite THEN  (* Don't even try. *)
>       RETURN;
>     END;
>     IF ww.current # NIL THEN  (* Don't ever write the records out of order. *)
>       <* ASSERT Compare(ww.current, fs) < 0 *>
>     END;
>     ww.current := fs;

Something's *really* screwed up.  I've never in 10 years seen this 
assertion fail.

John



More information about the M3devel mailing list