[M3devel] CM3 d5.5.0 CVSup client issues.

[Tony Hosking]

Sounds like we are losing some references somewhere and the GC is  
prematurely collecting live objects.  Alex, are you running on a 64- 
bit SPARC v9?  Perhaps the SaveRegsInStack code needs updating for  
that platform to use the flushw instruction instead of trap 3.  As it  
is, I am not entirely satisfied with the difficulties I've seen  
getting meaningful stack information on Solaris for stopped threads,  
but without a reliable way to diagnose the problem I don't know what  
to do from this end.  See additional comments below:

On Sep 7, 2007, at 12:04 AM, Alex Bochannek wrote:

> Tony, John,
>
> I ran the tests some more and noticed that there is always a problem
> with directory creation. The error I had mentioned before:
>
> Updater failed: Cannot create directories leading to "/opt/cm3/cm3- 
> cvs/cm3/caltech-parser/#cvs.cvsup-15483.1": Resource temporarily  
> unavailable
>
> happens pretty reliably whenever a directory (in this case
> caltech-parser) needs to be created regardless of the options
> below. This is running as root and cvsup not running setuid. I copied
> the directory structure froman existing tree to even get the  
> examples to
> run. (There is also an unrelated question for John below, please  
> read on.)
>
> Tony Hosking <hosking at cs.purdue.edu> writes:
>
>> We are using the native threads package here, unless Alex has built
>> without it.  Alex, can you try running with each of the following
>
> Here's what I have the cvsup linked against:
>
> ldd /usr/local/bin/cvsup
>         libXaw.so.5 =>   /usr/lib/libXaw.so.5
>         libXmu.so.4 =>   /usr/lib/libXmu.so.4
>         libXext.so.0 =>  /usr/lib/libXext.so.0
>         libXt.so.4 =>    /usr/lib/libXt.so.4
>         libX11.so.4 =>   /usr/lib/libX11.so.4
>         libsocket.so.1 =>        /lib/libsocket.so.1
>         libnsl.so.1 =>   /lib/libnsl.so.1
>         libw.so.1 =>     /lib/libw.so.1
>         libdl.so.1 =>    /lib/libdl.so.1
>         libpthread.so.1 =>       /lib/libpthread.so.1
>         libthread.so.1 =>        /lib/libthread.so.1
>         librt.so.1 =>    /lib/librt.so.1
>         libm.so.2 =>     /lib/libm.so.2
>         libc.so.1 =>     /lib/libc.so.1
>         libSM.so.6 =>    /usr/openwin/lib/libSM.so.6
>         libICE.so.6 =>   /usr/openwin/lib/libICE.so.6
>         libmp.so.2 =>    /lib/libmp.so.2
>         libmd5.so.1 =>   /lib/libmd5.so.1
>         libscf.so.1 =>   /lib/libscf.so.1
>         libaio.so.1 =>   /lib/libaio.so.1
>         libdoor.so.1 =>  /lib/libdoor.so.1
>         libuutil.so.1 =>         /lib/libuutil.so.1
>         /platform/SUNW,Sun-Fire-480R/lib/libc_psr.so.1
>         /platform/SUNW,Sun-Fire-480R/lib/libmd5_psr.so.1
>
>> flag combinations and report the results:
>>
>> @M3nogc
>
> With the nogc options cvsup pretty much always runs all the way to
> completion. It takes a while, especially on an existing tree, but it
> will complete without problems.

When you say "pretty much" what do you mean?  Does it sometimes get  
an error?  Is it the one you note above?

> Trying the following failed:
>
>> @M3noincremental @M3nogenerational @M3paranoidgc
>>
>> @M3noincremental @M3paranoidgc
>>
>> @M3nogenerational @M3paranoidgc
>>
>> @M3paranoidgc
>
> -bash-3.00$ /usr/local/bin/cvsup  -g cvsupfile.cm3
> Connected to birch.elegosoft.com
> Updating collection cm3/cvs
>  SetAttrs cm3/COPYRIGHT-BSD,v
>  SetAttrs cm3/COPYRIGHT-CMASS,v
>  SetAttrs cm3/COPYRIGHT-COLUMBIA,v
>  SetAttrs cm3/COPYRIGHT-DEC,v
>  SetAttrs cm3/COPYRIGHT-JDP,v
>  SetAttrs cm3/COPYRIGHT-PURDUE,v
>  SetAttrs cm3/COPYRIGHT-XEROX,v
>  SetAttrs cm3/COPYRIGHTS,v
>  SetAttrs cm3/README,v
>  SetAttrs cm3/caltech-parser/COPYRIGHT,v
>  SetAttrs cm3/caltech-parser/Makefile,v
>
>
> ***
> *** runtime error:
> ***    Segmentation violation - possible attempt to dereference NIL
> ***    pc = 0x715c4 = PutCollectionList + 0x6d4 in ../src/TreeList.m3
> ***

We may have collected something prematurely.

> Abort
> -bash-3.00$ /usr/local/bin/cvsup @M3noincremental @M3nogenerational  
> @M3paranoidgc -g cvsupfile.cm3
> Connected to birch.elegosoft.com
>
>
> ***
> *** runtime error:
> ***    Segmentation violation - possible attempt to dereference NIL
> ***    pc = 0x715c4 = PutCollectionList + 0x6d4 in ../src/TreeList.m3
> ***
>

Ditto

> Abort
> -bash-3.00$ /usr/local/bin/cvsup @M3noincremental @M3paranoidgc -g  
> cvsupfile.cm3
> Connected to birch.elegosoft.com
>
>
> ***
> *** runtime error:
> ***    Segmentation violation - possible attempt to dereference NIL
> ***    pc = 0x715c4 = PutCollectionList + 0x6d4 in ../src/TreeList.m3
> ***

Ditto

> Abort
> -bash-3.00$ /usr/local/bin/cvsup @M3nogenerational @M3paranoidgc -g  
> cvsupfile.cm3
> Connected to birch.elegosoft.com
>
>
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "../src/runtime/common/RTCollector.m3", line 1770
> ***

This is the collector complaining that it found a reference in the  
heap to an object that has been reclaimed.

> Abort
> -bash-3.00$ /usr/local/bin/cvsup @M3paranoidgc -g cvsupfile.cm3
> Connected to birch.elegosoft.com
>
>
> ***
> *** runtime error:
> ***    Segmentation violation - possible attempt to dereference NIL
> ***    pc = 0x421638 = NoteStackLocations + 0xac in ../src/runtime/ 
> common/RTCollector.m3
> ***
>

Looks like a bad sp error.

> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "../src/runtime/common/RTCollector.m3", line 688
> ***

This is knock-on from the previous error.

>
> Abort
> -bash-3.00$
>
>
> I hope this helps and that you can get to the bottom of this.
>
> I am trying to compile a new CVSup to see why I keep getting checksum
> mismatches that result in very long transfer times. I didn't think  
> that
> when CVSup runs on a busy repository, that I should get those a  
> lot, but
> especially during tagging operations, it seems like I end up with
> transferring the entire repository.
>
> Alex.