[M3devel] CVSup crashing WAS: Re: m3gdb and YACC
Tony Hosking
hosking at cs.purdue.edu
Sat Jul 11 18:21:28 CEST 2009
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/61df4bf9/attachment-0002.html>
More information about the M3devel
mailing list