PCB shuts down after opening file with empty Connect("")

[Joe Rowan]

After editing a schematic in gschem and using gsch2pcb to create a new netlist, a space was left at the end of a net after a line continuation character. This led to an empty connect statement in the net after import to the PCB file [Connect("")] and after this PCB would immediately shut down on opening the file without leaving any error record, even when started from a command line. The PCB file is OK after removing the connect statement.
The net with the space was the last entry in the netlist file, and before the schematic was edited, that entry had run onto the next line after a continuation character but was now shorter.

[Peter TB Brett (peter-b)]

Hi Joe,

I'd like to try and stop gsch2pcb from emitting broken netlists. :-) Do you by any chance have a minimal schematic that causes the "space after line continuation char" problem?

[Peter TB Brett (peter-b)]

Waiting for steps to reproduce with gnetlist.

[Joe Rowan (joe-zw)]

On Sun, 11 Dec 2011 08:58:40 -0000
Peter TB Brett <email address hidden> wrote:

> Hi Joe,
>
> I'd like to try and stop gsch2pcb from emitting broken netlists. :-)
> Do you by any chance have a minimal schematic that causes the "space
> after line continuation char" problem?
>
Sorry, I haven't been able to simplify this without breaking the
breakage, but it's not huge, and it's easy to see where the problem
is, though not what causes it.

The file LC-1-1m.sch produces a good netlist, LC-1-1n.sch produces the
problem one. Two components have been disconnected from the '+5V main'
rail and two new ones added to it, plus other parts added. I have
not been able to reproduce this behaviour by adding and removing
parts with simpler schematics, the line continuation character and
return always seem to be removed correctly. This does appear to be quite
a rare error, and sheer fluke that I hit on it.

The file test2.prj will produce a damaged netlist. Unfortunately many
custom components are used, but the netlist is exactly the same (no
output from diff) when the libraries are available, so with luck it is
of use to you. The PCB file produced is obviously missing many parts,
but the file test-no-netlist.pcb has been produced from the same sources
with the custom parts included. The faulty netlist can be imported into
it correctly but no ratlines are available, and once closed, the pcb
file can never be opened again. Removing the empty Connect fixes it
instantly and there is then no sign of any deviation from the original
schematics.

The current PCB in Debian sid is 20110918 with GTK (see screenshot.png)
which behaves almost the same as the earlier version with the empty
Connect except it now says 'segmentation fault' when started from a
console. I neglected to note the versions of gschem and PCB when the
problem occurred, and sid changes frequently, but the current versions
still behave the same (gschem 1.6.2.20110115).

Please let me know if I can be of further help. I can assemble the
custom parts and footprints into one place if required, but it would
help if it wasn't necessary.

Best regards,
Joe Rowan

[Peter TB Brett (peter-b)]

> The file test2.prj will produce a damaged netlist.

I've checked 'gsch2pcb test2.prj' output for both 1.6.2 and unstable head, and there's no sign of any line continuation characters in either test2-new.net or test2-new.pcb... this is proving hard to reproduce. :-(

[Joe Rowan (joe-zw)]

On Sun, 18 Dec 2011 10:50:05 -0000
Peter TB Brett <email address hidden> wrote:

> > The file test2.prj will produce a damaged netlist.
>
> I've checked 'gsch2pcb test2.prj' output for both 1.6.2 and unstable
> head, and there's no sign of any line continuation characters in
> either test2-new.net or test2-new.pcb... this is proving hard to
> reproduce. :-(
>

Right, I've just made a new directory, put in the two source files, run
gsc2pcb test2.prj in it and created the three output files. The .net
has the trailing continuation character.

So it's either the environment here or a library issue, as I assume
gsch2pcb uses the system gafrc file. Many of the components are custom,
so it's entirely possible one or more is broken. That's still worth
chasing, I think, as I'm not the only one building components, and I'm
not aware of anything I've done wrong. I'm still hoping, when I get the
time, to upload them to geda-symbols, so I'll need to identify the
faulty one(s). The problem there is that any change at all I have so
far made to the schematic has removed the problem, so it's probably
a combination of a faulty component definition and very bad luck in the
order of adding and removing things.

I think perhaps that this shouldn't be pursued any further. It's
obviously a one-in-a-million chance that I have found this, even on my
system, and it's probably one of my components at fault, so with luck
nobody else will ever see it. Unfortunately I am extremely pushed for
time at the moment, and if I can identify the problem at all, it will
take a couple of extremely tedious days. Obviously if I do learn
anything I'll report it.

Thank you for your time and effort.
Joe