[M3devel] CVSup crashing WAS: Re: m3gdb and YACC
Tony Hosking
hosking at cs.purdue.edu
Sat Jul 11 19:12:19 CEST 2009
Not sure how it happened, but the collector was turned off by
default. It works for me now with the latest updates.
On 11 Jul 2009, at 12:21, Tony Hosking wrote:
> Weird. I've just noticed that the collector has been disabled in
> RTCollector.i3 (not sure why I did that, but it had something to do
> with Jay's changes to the locking code in ThreadPThread). It should
> definitely be reverted, but probably exposes some weirdness in Jay's
> mutex initialization code. Jay, can you help?
>
>
> On 11 Jul 2009, at 11:19, Tony Hosking wrote:
>
>> I'd definitely need some way to reproduce the problem. Detailed
>> instructions would be best. What platform are you running on?
>>
>> On 11 Jul 2009, at 06:47, Olaf Wagner wrote:
>>
>>> Hm, I'm afraid we may have a regression in the runtime/gc here.
>>> CVSup always worked without problems for me (and still is copying
>>> FreeBSD, CM3 and other repositories between various machines for
>>> me and Elego). Surely CVSup is doing no such thing as keeping
>>> all its files in memory.
>>>
>>> I haven't tried the version Jay put into the CM3 repo though.
>>> So I see three possibilities:
>>>
>>> o Jay introduced the problem in the CVSup sources when he
>>> adapted them to the current CM3 (low probability).
>>>
>>> o You've got a broken runtime / CM3 version (and current
>>> sources work). I'd guess you are using the current version though.
>>>
>>> o We've got a problem in our runtime code, perhaps -- but not
>>> necessarily -- the garbage collector.
>>>
>>> I'd suggest we rule out the second one and you reproduce the problem
>>> with a current source set (if not done yet). Then let's see what Jay
>>> and Antony have to say, as they did almost all the source changes
>>> in that area recently.
>>>
>>> Olaf
>>>
>>> Quoting Peter Eiserloh <eiserlohpp at yahoo.com>:
>>>
>>>> Hi Olaf,
>>>>
>>>> Well, I tried CVSup, and it started looking real good, until
>>>> it crashed, with a message from the M3 runtime, saying that
>>>> NEW could not allocate any memory.
>>>>
>>>> So I ran it a second time, and it got further, then crashed
>>>> again.
>>>>
>>>> So, a third time, but with "top" running in another window,
>>>> and sure enough cvsup, was allocating something like 1.2 GB
>>>> of data before it was crashing. This is bigger than the
>>>> CVS repository that it had already downloaded.
>>>>
>>>> I am thinking that cvsup is keeping the contents of every
>>>> file it downloaded in memory. If so, this is a problem.
>>>>
>>>> If it is properly removing references, then maybe the
>>>> garbage collector is failing. This would be a bigger
>>>> problem, but with our compiler's runtime library.
>>>>
>>>> Are other people noticing problems. Is it just me?
>>>> Am I the only one to attempt downloading the entire
>>>> CVS repository for CM3? Could you try it?
>>>>
>>>>
>>>> I sent an email to the email listed in cvsup's "about box"
>>>> (cvsup-bugs at polstra.com), but that failed. The email address
>>>> no longer works.
>>>>
>>>> peter at black:/data/modula-3/cm3 $ debian-pkg/current/debian/tmp/
>>>> usr/lib/cm3/bin/cvsup cvsupfile.cm3
>>>>
>>>> ***
>>>> *** runtime error:
>>>> *** NEW() was unable to allocate more memory.
>>>> *** file "../src/runtime/common/RuntimeError.m3", line 63
>>>> ***
>>>>
>>>> Aborted
>>>>
>>>> Peter
>>>>
>>>>
>>>> +--------------------------------------------------------+
>>>> | Peter P. Eiserloh |
>>>> +--------------------------------------------------------+
>>>>
>>>>
>>>> --- On Sat, 7/11/09, Olaf Wagner <wagner at elegosoft.com> wrote:
>>>>
>>>>> From: Olaf Wagner <wagner at elegosoft.com>
>>>>> Subject: Re: m3gdb and YACC
>>>>> To: "Peter Eiserloh" <eiserlohpp at yahoo.com>
>>>>> Date: Saturday, July 11, 2009, 2:49 AM
>>>>> Quoting Peter Eiserloh <eiserlohpp at yahoo.com>:
>>>>>
>>>>> > Hi Olaf,
>>>>> >
>>>>> > The import script (git-importcvs) internally uses
>>>>> cvsps, which
>>>>> > you may already have.
>>>>> >
>>>>> > Anyways, here is the first ten lines from a log file
>>>>> of an import
>>>>> > that I just started.
>>>>> >
>>>>> >
>>>>> > peter at black:~ $ head Import-cm3-20090708.log
>>>>> > Running cvsps...
>>>>> > WARNING: revision 1.1.3.1 of file
>>>>> m3-sys/m3cc/gcc/etc/make-stds.texi on unnamed branch
>>>>> > WARNING: revision 1.1.3.1 of file
>>>>> m3-sys/m3cc/gcc/gcc/config/vax/vax.c on unnamed branch
>>>>> > WARNING: revision 1.1.3.1 of file
>>>>> m3-sys/m3cc/gcc/texinfo/config.h.in on unnamed branch
>>>>> > WARNING: revision 1.1.3.1 of file
>>>>> m3-sys/m3cc/gcc/texinfo/po/Makefile.in.in on unnamed branch
>>>>> > WARNING: revision 1.1.3.1 of file
>>>>> m3-sys/m3cc/gcc/.brik on unnamed branch
>>>>> > WARNING: revision 1.1.3.1 of file
>>>>> m3-sys/m3cc/gcc/texinfo/INTRODUCTION on unnamed branch
>>>>> > WARNING: revision 1.1.3.1 of file
>>>>> m3-sys/m3cc/gcc/gcc/config/i386/osfelf.h on unnamed branch
>>>>> > WARNING: revision 1.1.3.1 of file
>>>>> m3-sys/m3cc/gcc/gcc/config/mips/sni-svr4.h on unnamed
>>>>> branch
>>>>> > WARNING: revision 1.1.3.1 of file
>>>>> m3-sys/m3cc/gcc/gcc/config/v850/lib1funcs.asm on unnamed
>>>>> branch
>>>>>
>>>>> It looks like these files have a second vendor branch
>>>>> without a
>>>>> proper name. CVS does not cope well with multiple vendor
>>>>> branches
>>>>> (in fact it never really worked), but there won't be any
>>>>> valuable
>>>>> information in that branch I'm sure, so you can ignore it.
>>>>>
>>>>> > Later this weekend, I will attempt to use CVSup.
>>>>> First,
>>>>> > I will have to find usable documentation, since I
>>>>> have
>>>>> > never used CVSup before.
>>>>> >
>>>>> > Do you have a script to use with CVSup to access the
>>>>> > CM3 CVS repo? I am lasy.
>>>>> >
>>>>> > I use 'git' for all my current projects. I used
>>>>> to use
>>>>> > CVS, and had started looking into using subversion
>>>>> (SVN),
>>>>> > I even purchased a couple books on SVN. Then
>>>>> 'git' burst
>>>>> > upon the Linux world, and is gaining converts all over
>>>>> the
>>>>> > place.
>>>>> >
>>>>> > It really does provide a better work-flow. The
>>>>> easy
>>>>> > creation of a branch is a given, it is git's ability
>>>>> > to do easy merges, which is gaining all the good
>>>>> reputation.
>>>>> >
>>>>> > Rather than get all evangelistic on you, as I am sure
>>>>> you
>>>>> > have already heard it many times already.
>>>>> >
>>>>> > Many businesses are moving to git. The only
>>>>> problem some
>>>>> > enterprise companies are having is the ability to
>>>>> restrict
>>>>> > access of authorized users to only portions of the
>>>>> repository.
>>>>> > These types of problems don't effect open source
>>>>> software
>>>>> > development.
>>>>> >
>>>>> > Once I have a working 'git' repository for cm3, I will
>>>>> share
>>>>> > the technique, and maybe, start the foundations for a
>>>>> > transition from CVS, towards 'git'. But I
>>>>> suggest a slow
>>>>> > process, with distinct stages. At any
>>>>> stage we could stop,
>>>>> > or even revert.
>>>>> >
>>>>> > The problem is that once people start using git, they
>>>>> don''t
>>>>> > want to go back to using CVS, or any of the older
>>>>> methods.
>>>>> > Maybe that isn't so much of a problem after all.
>>>>> >
>>>>> > STAGE-1: Simple mirror of the CVS archive,
>>>>> periodically
>>>>> > updated (say once
>>>>> every 6 hours). Document on
>>>>> > web site, as to how
>>>>> to clone, and update a git
>>>>> > repository. No
>>>>> uploads to git.
>>>>> > STAGE-2: Convert web page scripts to use git.
>>>>> > STAGE-3: Convert tinderbox.
>>>>> > STAGE-4: Uploads to git. Install gitosis or
>>>>> similar server
>>>>> > for git uploads.
>>>>> Document the upload process on web
>>>>> > pages.
>>>>> > STAGE-5: CVS mirrors the git repo. Uploads to
>>>>> git only.
>>>>> > STAGE-6: Move last of the CVS people, over to git.
>>>>> > STAGE-7: Remove CVS. (optional)
>>>>>
>>>>> Let's see how far you get. Converting all the
>>>>> infrastructure (scripts
>>>>> and documentation) may be much more work than you imagine.
>>>>> And one
>>>>> we propose a special tool (be it git or svn or mercurial)
>>>>> there will
>>>>> start discussions on what is best and what we should do
>>>>> :-/
>>>>>
>>>>> So offering an optional alternative access may be a good
>>>>> plan.
>>>>> The majority of users should agree that they want the
>>>>> change though.
>>>>> And we need to consider use of GUIs and Windows users,
>>>>> too.
>>>>>
>>>>> Olaf
>>>>> --Olaf Wagner -- elego Software Solutions GmbH
>>>>>
>>>>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355
>>>>> Berlin, Germany
>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345
>>>>> 869 fax: +49 30 23 45 86 95
>>>>> http://www.elegosoft.com |
>>>>> Geschäftsführer: Olaf Wagner | Sitz: Berlin
>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 |
>>>>> USt-IdNr: DE163214194
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Olaf Wagner -- elego Software Solutions GmbH
>>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin,
>>> Germany
>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30
>>> 23 45 86 95
>>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz:
>>> Berlin
>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
>>> DE163214194
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090711/a068aa59/attachment-0002.html>
More information about the M3devel
mailing list