[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