[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: gschem crash on object drag



   So..
   I tried it on a newer version of gschem (20110115 running on someone
   else's machine) and the behaviour was the same. Turned out it happens
   whenever there is any wire inside a symbol.
   I read somewhere on the mailing list archives that wires may not be
   placed inside symbols. So I have modified my symbols - they now have a
   "source=Â " attribute and the content is in a schematic.
   The headache is that
   1. If, in the schematic, any 'pin' is shorted to any other 'pin' then
   gnetlist completely misses that connection.
   2. If, externally, one pin is shorted to another pin, then also the
   netlister completely misses the connection.
   I'm sure i'm doing something dumb here, so could someone please throw
   some light?
   P.S. I am posting the schematics and symbols here in case you want
   look:
   [1]http://www.cedt.iisc.ernet.in/people/students/kabhijit/gEDA/
   Page2_1 and page2_2 are the two schematics. You may need the gafrc also
   for gschem to find the correct schematics for the symbols.
   Thanks in advance!
   ~Abhijit

   On Wed, Aug 24, 2011 at 05:39, Peter Clifton <[2]pcjc2@xxxxxxxxx>
   wrote:

   On Tue, 2011-08-23 at 23:22 +0530, Abhijit Kshirsagar wrote:
   > Thanks. I will try with the newer version.
   > Â ÂAs of now I think the problem lies in one of the custom
   components I'm
   > Â Âusing - but that should still not cause a segfault right?`

     No - it should not.
     If you can still reproduce it in a newer gEDA version (or can find
     instructions to reproduce it reliably at your end with a minimal
     test-case), perhaps you could send us a copy of component causing
     the
     problem and we can investigate the problem further.

   > Â ÂAlso, ÂI'd have liked some inputs on how to debug the problem.
   Is
   > Â Âthere some way of enabling "debug" logging or something?

     Not that I recall. Running under "gdb"
     gdb --args pcb path_to_your_pcb_file.pcb
     then getting a backtrace with the "bt"<ENTER> command when it
     crashes
     might be useful.
     Running under "valgrind"
     valgrind pcb path_to_your_pcb_file.pcb
     Would be very slow, but is excellent at nailing the root cause of
     memory
     corruption problems which lead to crashes.
     Again - checking if you can reproduce the issue under a later gschem
     version is probably the most efficient way to proceed.
     --
     Peter Clifton
     Electrical Engineering Division,
     Engineering Department,
     University of Cambridge,
     9, JJ Thomson Avenue,
     Cambridge
     CB3 0FA
     Tel: +44 (0)7729 980173 - (No signal in the lab!)
     Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)
     _______________________________________________
     geda-user mailing list
     [3]geda-user@xxxxxxxxxxxxxx
     [4]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

References

   1. http://www.cedt.iisc.ernet.in/people/students/kabhijit/gEDA/
   2. mailto:pcjc2@xxxxxxxxx
   3. mailto:geda-user@xxxxxxxxxxxxxx
   4. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

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