X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to;
        bh=hBmF8uHi3NJyNwsTyB0Pmys9Ip3IxtP9TF769GR97aY=;
        b=z8QJOI57A9T3zBsgUtLATy/xg1NvJi5KQmsNwcW2XrEjSkfvV3NJoWEEyylALMV+kX
         pDIPimj2tsWmC/NdwcEFU4sPaZBbo/arhwt2l+rEaVoD7bAM7HFV2axWBjtyrzCz8AQL
         n/ml3/CTiiv0kdi+tuO62uLkwT/lZV6bjVep1TAnbMb7JHue+d/KUKzBeUmB98loXjfo
         wiV9Ahy8f49vSVAetQJfwlp7GGlXCjIZQWXCzsRQwUmnrKCSOJVvvuOghQY5q2zZbtKU
         2mNxplGzH9dLX5SovN3BhhHo8rJSYWv11/8Uq7/chwqPRmqX+D+Xnjlo/4DLDnRmCUXt
         t/sw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:mime-version:in-reply-to:references:date
         :message-id:subject:from:to;
        bh=hBmF8uHi3NJyNwsTyB0Pmys9Ip3IxtP9TF769GR97aY=;
        b=C5VzxMJ/TIpvaACQnQkEzKnhzYDTq9fZbpqh5mUJ3d3TshjzNrzZTV+BHWMtLEr13c
         MHUZQD2IyGQ2qFjLIyD4fD/A9QazzYzDx/zWSYQVu2XPZFkObeP5nFWZSLhvWvxa1ShW
         GHLzSJLK4ZHoxtls0PKV7H5fyctuBI/K1+7iLR+2PPNb8Sek2+2vadUXHy93hJgDqtoq
         drvVnPQE9U5vVgzSAQGZQS9f0MuRiLIESvOsmxIt4rlx52XG/UfWUoBo/UNqV3aSbfUq
         1/TCVqqssXR/+uNVPfqkZGMnAcAAfErz/4bOHnpb4Jfc6m0zbjXtGbWghsrohxM0drRB
         Of4w==
X-Gm-Message-State: AD7BkJKxt5R0ZknBRjn77dPskUtMGXtmWnm5ZezSEDT2zL3jgCO9uyaEOMr8eYTNikGWHx8/GFAdkmdaCcfj6g==
MIME-Version: 1.0
X-Received: by 10.28.30.132 with SMTP id e126mr1403411wme.42.1456737998754;
 Mon, 29 Feb 2016 01:26:38 -0800 (PST)
In-Reply-To: <20160228183227.Horde.g66UEijK5I0FnHyBsmI3bZU@webmail.in-berlin.de>
References: <20160223152120 DOT Horde DOT _z0FeIbOqDDq7i7gKTXCeK4 AT webmail DOT in-berlin DOT de>
	<94CB9E71-127E-4690-9FFC-39722F79260B AT noqsi DOT com>
	<20160228183227 DOT Horde DOT g66UEijK5I0FnHyBsmI3bZU AT webmail DOT in-berlin DOT de>
Date: Mon, 29 Feb 2016 12:26:38 +0300
Message-ID: <CAMvDHVCsqDvpRvXL-2BsPWGg5TqME9rtKk-xV+5um2kmnLFgQw@mail.gmail.com>
Subject: Re: [geda-user] hierarchical design - two symbols pointing to one schematic
From: "Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: geda-user AT delorie DOT com
Content-Type: text/plain; charset=UTF-8
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

Hagen,

On 2/28/16, Hagen SANKOWSKI <hsank AT nospam DOT chipforge DOT org> wrote:
> Hello.
>
> Thanks for your answer.
> During this week I rectify my design, but still ending up - after a long,
> long runtime something in hours on a VirtualBox with a lot of RAM and 4 CPUs
> -
> with a gnetlist line which said: Killed.

Well, I did 'git grep "[Kk]illed" in the geda-gaf repository and
found nothing but one word in the documentation for icarus. So I
suppose the OOM-killer kills your gnetlist when it goes into a big
loop for some reason and eats all the memory resources.

>
> Well, I tried to do my hierarchical design a little bit smaller and run
> just
> a sup-page (which is still hierarchical) successfully thrue gnetlist.
>
> I got a bunch of lines from gnetlist for my hierarchical design like this:
> "Found a pin [Y300/Y2] on component [26] which does not have a label!"
>
> Well, I found the Source Code via DuckDuckGo here (sorry for the bad
> reference!)
> http://ljh4timm.home.xs4all.nl/gaf/dox_gnetlist/s__hierarchy_8c_source.html
>
> IMHO the arguments for the fprint(stderr, ..) function should be swapped.
>
> 00206                 nl_current->component_uref,
> 00207                 pl_current->pin_number);
>
> The first argument should be the pin number, the second one should be
> the component.
> This lines, I guess, are coming from hidden VDD and GND nets inside my
> hierachichal
> symbols.
>
> Nevertheless I like to feed my whole gschem-Design now into PCB now.
> So who is killing my gnetlist-process inside gsch2pcb? Any suggestion how
> to
> find/avoid the reason for the gnetlist-death?

Probably the best way to find the culprit is to start with some
little schematic and make it more complex step by step every
time checking if your forward annotation process works correctly.

There is the gschem->gsch2pcb->PCB tutorial in the wiki [1], you
can use it as an example.

HTH,
  Vladimir

[1] http://wiki.geda-project.org/geda:gsch2pcb_tutorial