[M3devel] CVSup crashing WAS: Re: m3gdb and YACC
jay.krell at cornell.edu
jay.krell at cornell.edu
Mon Jul 13 08:53:28 CEST 2009
Am I off the hook? Mika you often test user mode threads right? :)
Starting with gc off isn't obviously definitely wrong, could be it
gets enabled once initialization is further along. Or not.
- Jay (phone)
On Jul 12, 2009, at 12:17 PM, Tony Hosking <hosking at cs.purdue.edu>
wrote:
> You should find the footprint much smaller now. I'm interested to
> find out what it turns out to be.
>
> On 12 Jul 2009, at 14:26, Peter Eiserloh wrote:
>
>>
>> Hi Tony,
>>
>> Okay, I am downloading cm3-src-all-d5.8.1-2009-07-12-12-08-57.tgz
>> right now.
>>
>> In the mean time, I wish to report that CVSup on PPC_DARWIN
>> built against cm3-src-all-d5.8.1-2009-07-11-12-09-23.tgz,
>> did run to completion. Top indicated that over 2 GB of
>> virtual memory was being used, and over 700 MB of resident
>> memory (ie, RAM).
>>
>> CVSup, used most of my CPU, making any other process (such
>> as Finder) very difficult from which to work. Maybe we should
>> "nice" it, or recommend is be run with "nice". Oh, well
>> one thing at a time.
>>
>> BTW: The "about" box, found by clicking on the little "i" icon
>> in the lower right corner is woefully out of date (eg. I had
>> tried to report bugs to cvsup-bugs at polstra.org, but the email
>> failed to get delivered). The copyright is also listed as 2003,
>> six years ago.
>>
>> The reference to cvsup.org does work however.
>>
>>
>> Peter
>>
>>
>> +--------------------------------------------------------+
>> | Peter P. Eiserloh |
>> +--------------------------------------------------------+
>>
>>
>> --- On Sat, 7/11/09, Tony Hosking <hosking at cs.purdue.edu> wrote:
>>
>>> From: Tony Hosking <hosking at cs.purdue.edu>
>>> Subject: Re: [M3devel] CVSup crashing WAS: Re: m3gdb and YACC
>>> To: "Peter Eiserloh" <eiserlohpp at yahoo.com>
>>> Cc: "Olaf Wagner" <wagner at elegosoft.com>, m3devel at elegosoft.com
>>> Date: Saturday, July 11, 2009, 2:31 PM
>>> Please try my recent commits from
>>> earlier to day.
>>>
>>> On 11 Jul 2009, at 16:10, Peter Eiserloh wrote:
>>>
>>>>
>>>> Hi Tony,
>>>>
>>>> Architecture: AMD64_LINUX.
>>>> Code base: 20090628.
>>>>
>>>> I am untarring 20090710 right now, and will rebuild
>>> the
>>>> CM3 against it using the standard
>>> scripts/do-cm3-std.sh
>>>>
>>>> I don't expect any difference in behavior though as
>>> that
>>>> is pretty much what my Makefile does anyways.
>>>>
>>>> Okay, I can also try this on my old Macintosh
>>> (PPC_DARWIN).
>>>>
>>>>
>>>> Are there any additional diagnostics that I can turn
>>> on
>>>> in the runtime? Something simple may help like
>>> when NEW
>>>> complains, printing out:
>>>> o the size of memory currently allocated,
>>>> o the current number of allocations,
>>>> o the total number of allocations performed,
>>>> o the number of garbage collection runs
>>> performed, and
>>>> o the number of objects reclaimed by the garbage
>>> collector,
>>>> and so forth.
>>>>
>>>> This may be difficult since we just failed to
>>> allocate,
>>>> memory, the diagnostics may not have the ability to
>>>> format strings for output.
>>>>
>>>>
>>>>
>>> +--------------------------------------------------------+
>>>> | Peter P. Eiserloh
>>>
>>> |
>>>>
>>> +--------------------------------------------------------+
>>>>
>>>>
>>>> --- On Sat, 7/11/09, Tony Hosking <hosking at cs.purdue.edu>
>>> wrote:
>>>>
>>>>> From: Tony Hosking <hosking at cs.purdue.edu>
>>>>> Subject: Re: [M3devel] CVSup crashing WAS: Re:
>>> m3gdb and YACC
>>>>> To: "Olaf Wagner" <wagner at elegosoft.com>
>>>>> Cc: "Peter Eiserloh" <eiserlohpp at yahoo.com>,
>>> m3devel at elegosoft.com
>>>>> Date: Saturday, July 11, 2009, 8:19 AM
>>>>> 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/20090712/c4a849ad/attachment-0002.html>
More information about the M3devel
mailing list