Re: gEDA-user: gnetlist segmentation fault

2010-09-29 Thread Patrick Bernaud
Hi John,

John Doty writes:
  [...]
  This is a coding error somewhere. There should be nothing wrong with an 
  empty string as an attribute: it's a perfectly good string.

No, actually, an attribute is required to have a value, see
documentation (and code) for o_attrib_string_get_name_value() in
libgeda/src/o_attrib.c.

Regards,


Patrick


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: gnetlist segmentation fault

2010-09-29 Thread Patrick Bernaud
Thomas Dean writes:
  I have an application which causes a seg fault in gnetlist.  I think
  this can be fixed by changing the schematic.  But, Segmentation fault
  is NEVER the proper response.

Your issue is similar to bug #3032626 (a malformed attribute as
Kai-Martin explained). I have proposed a patch that is under review.

Thank you for the report.

Regards,


Patrick


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: gnetlist segmentation fault

2010-09-29 Thread John Doty

On Sep 29, 2010, at 3:31 AM, Patrick Bernaud wrote:

 Hi John,
 
 John Doty writes:
 [...]
 This is a coding error somewhere. There should be nothing wrong with an 
 empty string as an attribute: it's a perfectly good string.
 
 No, actually, an attribute is required to have a value,

There seems to be no good design reason for this restriction: an empty string 
is still a perfectly good string, just as zero is a perfectly good number.

 see
 documentation

Perhaps it would be better to remove this restriction from both the code and 
documentation. That would simplify the documentation, and possibly the code, 
too.

 (and code) for o_attrib_string_get_name_value() in
 libgeda/src/o_attrib.c.
 
 Regards,
 
 
 Patrick
 
 
 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
 

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: gnetlist segmentation fault

2010-09-29 Thread DJ Delorie

  No, actually, an attribute is required to have a value,
 
 There seems to be no good design reason for this restriction: an
 empty string is still a perfectly good string, just as zero is a
 perfectly good number.

I agree, this caused me problems during the final phases of my last
board - I wanted to leave the attribute names alone but wipe out the
values for part numbers that I knew were wrong, so I could replace
them later.  Sometimes, I wanted to wipe them out so I could replace
them *immediately* but as soon as the dialog lost focus (so I could
copy text from elsewhere) it tried to close the attribute and
complained.  Cut and paste is horribly non-intuitive in gschem and
gattrib.  Specifically:

* Clicking on a cell in gattrib should not do a copy

* Moving the focus away from a value field in gschem's attribute
  editor should not attempt to save the attribute


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


gEDA-user: gnetlist segmentation fault

2010-09-28 Thread Thomas Dean
I have an application which causes a seg fault in gnetlist.  I think
this can be fixed by changing the schematic.  But, Segmentation fault
is NEVER the proper response.

# gnetlist -g geda ulf-ant.sch
Loading schematic [/usr/home/tomdean/Electronics/Spice/ulf-ant/ulf-ant.sch]
Segmentation fault (core dumped)

tomdean

ulf-ant.sch=
v 20100214 2
C 19500 47500 1 0 0 lf353-1.sym
{
T 19500 48600 5 10 1 1 0 0 1
refdes=U101A
T 19500 48400 5 10 1 1 0 0 1
device=AD797
T 19500 47500 5 10 0 0 0 0 1
slot=1
}
C 19500 42700 1 180 1 lf353-1.sym
{
T 19600 41700 5 10 1 1 180 6 1
refdes=U102A
T 19600 41400 5 10 1 1 0 0 1
device=AD797
T 19500 42700 5 10 0 0 0 0 1
slot=1
}
C 28500 45400 1 0 0 lf353-1.sym
{
T 28500 46700 5 10 1 1 0 0 1
refdes=U103A
T 28500 46500 5 10 1 1 0 0 1
device=AD797
T 28500 45400 5 10 0 0 0 0 1
slot=1
}
C 18500 47200 1 90 0 resistor-1.sym
{
T 18200 47400 5 10 1 1 90 0 1
refdes=R101
T 17700 46900 5 10 1 1 0 0 1
value=100Meg
}
C 27300 49100 1 270 1 capacitor-1.sym
{
T 27100 49200 5 10 1 1 90 2 1
refdes=C101
T 28200 49300 5 10 0 0 90 2 1
symversion=0.1
T 26800 49800 5 10 1 1 0 0 1
value=1000uf
}
C 15200 39800 1 0 0 title-B.sym
C 18500 42100 1 90 0 resistor-1.sym
{
T 18200 42300 5 10 1 1 90 0 1
refdes=R102
T 17700 43100 5 10 1 1 0 0 1
value=100Meg
}
C 26000 49100 1 270 1 resistor-1.sym
{
T 26300 49300 5 10 1 1 90 2 1
refdes=R103
T 26700 49300 5 10 1 1 90 0 1
value=10k
}
C 26000 48100 1 270 1 resistor-1.sym
{
T 26300 48300 5 10 1 1 90 2 1
refdes=R104
T 26700 48300 5 10 1 1 90 0 1
value=10k
}
C 28100 49100 1 270 1 capacitor-1.sym
{
T 27900 49200 5 10 1 1 90 2 1
refdes=C102
T 29000 49300 5 10 0 0 90 2 1
symversion=0.1
T 27800 49800 5 10 1 1 0 0 1
value=100uf
}
N 30700 5 26100 5 4
{
T 30300 50100 5 10 1 1 0 0 1
netname=Vcc
}
N 26100 49100 26100 49000 4
C 25700 48800 1 0 1 gnd-1.sym
N 26100 48100 26100 48000 4
N 27500 48000 27500 49100 4
N 29100 49100 27500 49100 4
C 20400 47200 1 180 0 resistor-1.sym
{
T 20200 46900 5 10 1 1 180 0 1
refdes=R105
T 19700 46600 5 10 1 1 0 0 1
value=27k
}
C 19400 45400 1 90 0 resistor-1.sym
{
T 19100 45600 5 10 1 1 90 0 1
refdes=R106
T 19500 45800 5 10 1 1 0 0 1
value=1k
}
C 20400 43300 1 180 0 resistor-1.sym
{
T 20100 43500 5 10 1 1 180 0 1
refdes=R107
T 19600 43600 5 10 1 1 0 0 1
value=27k
}
N 19500 47700 19300 47700 4
N 19300 47700 19300 46300 4
{
T 18900 47400 5 10 1 1 0 0 1
netname=fb1
}
N 19500 42500 19300 42500 4
N 19300 42500 19300 44200 4
{
T 18900 43100 5 10 1 1 0 0 1
netname=fb2
}
N 19300 47100 19500 47100 4
N 19300 43200 19500 43200 4
N 20500 47900 20500 47100 4
N 20500 47100 20400 47100 4
N 20400 43200 20500 43200 4
N 20500 43200 20500 42300 4
C 21600 42400 1 180 0 resistor-1.sym
{
T 21400 42100 5 10 1 1 180 0 1
refdes=R108
T 20900 41800 5 10 1 1 0 0 1
value=27k
}
C 21600 48000 1 180 0 resistor-1.sym
{
T 21400 47700 5 10 1 1 180 0 1
refdes=R109
T 20900 47400 5 10 1 1 0 0 1
value=27k
}
N 20500 47900 20700 47900 4
{
T 20400 48200 5 10 1 1 0 0 1
netname=3
}
N 20500 42300 20700 42300 4
{
T 20600 42600 5 10 1 1 0 0 1
netname=4
}
N 18400 47200 18400 43000 4
N 2 42700 2 42800 4
{
T 19700 42900 5 10 1 1 0 0 1
netname=Vdd
}
N 2 41800 2 41900 4
{
T 20200 41700 5 10 1 1 0 0 1
netname=Vcc
}
N 2 47400 2 47500 4
{
T 20200 47300 5 10 1 1 0 0 1
netname=Vdd
}
N 2 48300 2 48400 4
{
T 20100 48500 5 10 1 1 0 0 1
netname=Vcc
}
C 29400 45100 1 180 0 resistor-1.sym
{
T 29200 44800 5 10 1 1 180 0 1
refdes=R115
T 28800 44500 5 10 1 1 0 0 1
value=27k
}
N 28300 45000 28500 45000 4
N 29600 45800 29600 45000 4
N 28300 45600 28300 44700 4
N 29000 45300 29000 45400 4
{
T 29100 45200 5 10 1 1 0 0 1
netname=Vdd
}
N 29000 46200 29000 46300 4
{
T 29100 46400 5 10 1 1 0 0 1
netname=Vcc
}
N 28300 43200 28300 43800 4
{
T 28500 43200 5 10 1 1 0 0 1
netname=GND
}
C 28900 49100 1 270 1 capacitor-1.sym
{
T 28700 49200 5 10 1 1 90 2 1
refdes=C103
T 29800 49300 5 10 0 0 90 2 1
symversion=0.1
T 28800 49800 5 10 1 1 0 0 1
value=1uf
}
C 31200 45900 1 180 0 resistor-1.sym
{
T 31000 45600 5 10 1 1 180 0 1
refdes=R117
T 30500 45300 5 10 1 1 0 0 1
value=47
}
N 31200 45800 31400 45800 4
{
T 31300 45900 5 10 1 1 0 0 1
netname=Vout
}
C 29600 48800 1 0 0 vdc-1.sym
{
T 30300 49450 5 10 1 1 0 0 1
refdes=V101
T 30300 49250 5 10 1 1 0 0 1
value=DC 6V
}
C 15700 46800 1 0 0 vsin-1.sym
{
T 16400 47450 5 10 1 1 0 0 1
refdes=V102
T 16400 47250 5 10 1 1 0 0 1
value=sin 0 1e-5 1khz
}
C 15700 42300 1 0 0 vsin-1.sym
{
T 16500 42850 5 10 1 1 0 0 1
refdes=V103
T 16300 42550 5 10 1 1 0 0 1
value=sin 0 1e-5 1khz
}
N 16000 48100 19500 48100 4
{
T 16300 48200 5 10 1 1 0 0 1
netname=1
}
N 16000 48100 16000 48000 4
N 16000 42100 19500 42100 4
{
T 16400 41800 5 10 1 1 0 0 1
netname=2
}
N 16000 42100 16000 42300 4
N 16000 46800 16000 43500 4
N 16000 45600 18400 45600 4
{
T 16100 45700 5 10 1 1 0 0 1
netname=GND
}
N 29600 45000 29400 45000 4
N 29500 45800 30300 45800 4
{
T 29600 46000 5 10 1 1 0 0 1
netname=9
}
T 24300 45700 9 10 1 0 0 0 1
100 ft. Twisted Pair (CAT-5)
C 

Re: gEDA-user: gnetlist segmentation fault

2010-09-28 Thread kai-martin knaak
Thomas Dean wrote:

 I have an application which causes a seg fault in gnetlist.  I think
 this can be fixed by changing the schematic. 

The offending symbol is A103 which refers to spice-include-1.sym
The symbol  contains a spurious attribute netname= with no value.


 But, Segmentation fault is NEVER the proper response.

The gsch2pcb back-end does not segfault but fails with:
 At least gnetlist 20030901 is required for m4-xxx options.
Looks like this is another incarnation of the infamous m4 parsing 
failure, that has been haunting geda users for years now.

 ulf-ant.sch=
 v 20100214 2
 C 19500 47500 1 0 0 lf353-1.sym
 {
(...)

 T 24300 45700 9 10 1 0 0 0 1
 100 ft. Twisted Pair (CAT-5)
 C 20500 49700 1 0 0 spice-include-1.sym
 {
 T 20600 50100 5 10 1 1 0 0 1
 refdes=A102
 T 21000 49800 5 10 1 1 0 0 1
 file=ad797.cir
 T 20500 49700 5 10 1 0 0 0 1
 netname=
 }
(...) 

I guess, the = at the end of the string is the trigger. If the 
attribute contains just a single letter, gnetlist is happy with the 
file. How did you manage to add the empty netlist attribute? IMHO, the 
attribute editor in the GUI ties to prevent empty string values.

Bottom line: The gnetlist really needs to be more fussy on the syntax. 
Currently it seems to assume m4 where there isn't. In addition, m4 
should fail gracefully rather than returning broken strings. 

---)kaimartin(---
-- 
Kai-Martin Knaak
Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: gnetlist segmentation fault

2010-09-28 Thread Thomas D. Dean
On Wed, 2010-09-29 at 01:19 +0200, kai-martin knaak wrote:
I believe this started with gschem.

However, I repeat, seg fault is NEVER a proper response.

tomdean



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: gnetlist segmentation fault

2010-09-28 Thread John Doty

On Sep 28, 2010, at 5:19 PM, kai-martin knaak wrote:

 Bottom line: The gnetlist really needs to be more fussy on the syntax. 
 Currently it seems to assume m4 where there isn't. In addition, m4 
 should fail gracefully rather than returning broken strings. 

Huh? Gnetlist has nothing to do with m4. M4's tricky relationship with pcb 
causes trouble, but that's pcb's problem.

This is a coding error somewhere. There should be nothing wrong with an empty 
string as an attribute: it's a perfectly good string.

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user