Mail Archives: geda-user/2012/09/23/10:51:31
I believe I have narrowed this down to a path related issue. I created
a new directory, copied the files down, pulled everything else out but
a trivial circuit, and it worked. Puzzled, I copied the original files
into this subfolder, and it works too.
gafrc:
(source-library ".")
(component-library ".")
(source-library "components")
(component-library "components")
~/projects/foo
~/projects/foo/top.sch
~/projects/foo/components/sub{1,2}.{sym,sch}
In the above case, sub2 works as expected, sub1 can descend only once
into the schematic. After that it will either fail, or descend into
sub2 instead.
~/projects/foo
~/projects/foo/top.sch
~/projects/foo/components/sub{1,2}.{sym,sch}
Simply by creating the folders
~/projects/foo/bugreport{,/components}
And copying top.sch, sub{1,2}.{sym,sch} into the respective
directories, it works 100% of the time. I can even have both
~/projects/foo/top.sch and ~/projects/foo/bugreport/top.sch open, and
the former will exhibit the behavior, the latter will not. (I've
always joked that bugs have some sort of primitive sentient, as well
as emotion. If it knows you're watching, it won't reproduce, and the
bug's ultimate goal is to embarrass you - as soon as you ask a stupid
question and embarass yourself, the bug has gotten what it wants, and
will usually give up the game at that point.)
Since it behaves in this manner I'll mention that there are no weird
punctuation/spaces or other escaped characters anywhere in the real
path to these folders.
On Sat, Sep 22, 2012 at 7:38 PM, Nathan Stewart
<therealnathanstewart AT gmail DOT com> wrote:
> I'm still trying to reduce my problem down to the simplest thing that
> doesn't work, but I have a hierarchical schematic which I can descend
> into once, but once I pop back up, attempting to descend into it again
> crashes the thread opening the schematic with the following error:
>
> (gschem:6087): GLib-CRITICAL **: g_strcasecmp: assertion `s2 != NULL' failed
>
> Perhaps unrelated, perhaps not - the netlister chokes the io pins in
> the schematic, saying:
> Missing I/O symbol with refdes [Out] inside schematic for symbol [S1]
> Missing I/O symbol with refdes [In] inside schematic for symbol [S1]
>
> When there most certainly are pins with the correct refdes.
>
> The dummy schematic I use for layout can descend into this symbol
> repeatedly with no issues, and the main schematic can descend into
> other schematics without problems. Also interesting is that renaming
> the pins/refdes seems to have cured the problem. Even renamed to the
> original name it works. Normally at this polnt I'd chalk it up to
> random wierdness and move on because I'm back in business - but the
> thing about working the first time, and not working on subsequent
> tries is worrisome, as is the fact that a different top level schem
> had no problems with the subschem in the first place. I attempted to
> take a look with gdb - but the thread it was in had already exited.
>
> Nathan
- Raw text -