From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 buffer1.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Natasha Kerensikova <lithiumcat@instinctive.eu>
Newsgroups: comp.lang.ada
Subject: Re: GNAT stuck, any idea on how to diagnose it?
Date: Mon, 15 Sep 2014 07:16:13 +0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <slrnm1d4hp.nrc.lithiumcat@nat.rebma.instinctive.eu>
References: <slrnm1anga.nrc.lithiumcat@nat.rebma.instinctive.eu>
 <vlxfpcmsetjg$.1em03ijtae3i6$.dlg@40tude.net>
Injection-Date: Mon, 15 Sep 2014 07:16:13 +0000 (UTC)
Injection-Info: mx05.eternal-september.org;
 posting-host="76a49b86bc3e16725b7cfca3d85cb4c8";
 logging-data="6013"; mail-complaints-to="abuse@eternal-september.org";
 posting-account="U2FsdGVkX19ubMDsPZbVcmf7WxKyWlzL"
User-Agent: slrn/1.0.1 (FreeBSD)
Cancel-Lock: sha1:PR6OjJSW0QpRX/341yMwXXXhTrI=
Xref: number.nntp.dca.giganews.com comp.lang.ada:189008
Date: 2014-09-15T07:16:13+00:00
List-Id: <comp.lang.ada>

Hello,

On 2014-09-14, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Sun, 14 Sep 2014 09:21:18 +0000 (UTC), Natasha Kerensikova wrote:
>
>> Would you know what is this `gnat1`?
>> What part of the build process is it?
>> What is the command above supposed to perform?
>> Is it known to occasionally take a lot of time?
>
> Yes. It may take relatively much time on its own, but from my experience, I
> can tell that GNAT consumes extremely and unreasonably much memory.
>
> At some point it stops compiling under 32-bit systems because there is not
> enough virtual memory.
>
> You could check if your problem is caused by exhaustion of the physical
> memory and turning to the swap. If swap gets involved it will never end.

As I wrote in the OP, the memory used by gnat1 process, as reported by
the operating system, was constant. Actual numbers depend on what is
measured, as is often the case in modern OS, but all of them where
constant, from 72 MB of physical memory to about 140 MB of addressable
space.

>From there, can we deduce that 100% CPU usage with constant memory usage
means the compiler is stuck?

Or are there parts of the compiling process that can legitimately a
significant amount of time without using extra memory?



Thanks for you comments,
Natasha