[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