[M3devel] CM3 d5.5.0 CVSup client issues.

Tony Hosking hosking at cs.purdue.edu
Thu Aug 23 16:27:15 CEST 2007


You don't need m3gdb to get back traces.  gdb works fine for that.

On Aug 22, 2007, at 11:53 PM, Alex Bochannek wrote:

> Tony Hosking <hosking at cs.purdue.edu> writes:
>
>>> o If I run it with -g -L 2, I get either:
>>
>> What do these flags do?
>
> Sorry, those are CVSup client flags. No GUI (-g) and verbosity level 2
> (-L 2).
>
>> 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.
>
>> 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;
>
>> Hmm...  How do we proceed in debugging this?
>
> If I had been able to build the m3gdb, maybe I could get backtraces  
> from
> the core files?
>
> Alex.




More information about the M3devel mailing list