Menu
▾
▴
[Tclspice-announce] Some notes and observations
|
From: <sd...@cl...> - 2003-07-12 18:11:24
|
Greetings, Stefan and Tclspicers --
Here are a few random notes and observations which may be of interest
to the community.
1. Stefan, I installed tclspice-0.2.12. It runs happily, and my poly
stuff seems to have been integrated successfully into the
release. I have not tested your cmpp yet; I will let you know
about my success or failure when I do that.
One funny note: When building tclspice, I find that I have to
first build regular ngspice, and then build tclspice afterwards.
That is, my build procedure is:
./configure --enable-xspice
make && make install
(makes regular ngspice)
./configure --enable-experimental --enable-tclspice --enable-xspice
make && make install
(makes tclspice)
If I don't do this, then the compilation process barfs when
compiling main.c because it is looking for tcl_fprintf and
tcl_printf, but can't find them. I don't know why this is
happening. It is also possible that I am doing something
wrong, but I don't think so. . . .
2. I have been using tclspice to do design optimization. I wrote a
TCL program which varies a bunch of circuit parameters in a SPICE
source file, does a SPICE .tran analysis, compares the resulting
waveform against a desired waveform, and then tries to find
circuit parameters which minimize the mean square difference
between the simulated and the desired waveform.
I am very pleased that the program is working. Thank you to
Stefan & everybody else for their great work on creating tclspice,
which has enabled me to do this! This is a great application, and
I am using it intensively!
However, there is one small problem: tclspice has a memory leak.
Therefore, I can't let the optimizer run for a long time, because
it doesn't take long for tclspice to eat up all memory in my
machine. I have run valgrind-1.9.6 [1] against tclspice; the valgrind
log is attached below. There are several leaks, but the main
one seems to be related to invoking the copy function in strings.c.
The invocation occurs when performing cp_addkword, as well as in
gettok. Since I still don't understand the big picture enough to
know what these programs are intending to do, I haven't tried to
fix these memory leaks. Perhaps a greater mind than mine can use
this info to fix the leaks. (Additionally, I would recommend
that a smarter person than I should try running valgrind on
tclspice to try fixing these memory leaks.)
------------------- begin valgrind log ---------------------------
==9963== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==9963== Copyright (C) 2002, and GNU GPL'd, by Julian Seward.
==9963== Using valgrind-1.9.6, a program instrumentation system for x86-linux.
==9963== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==9963==
==9963== My PID = 9963, parent PID = 1094. Prog and args are:
==9963== tclsh
==9963== Optimize.tcl
==9963==
==9963== Startup, with flags:
==9963== --suppressions=/home/binaries/lib/valgrind/default.supp
==9963== --leak-check=yes
==9963== --num-callers=10
==9963== --logfile=ValgrindLog
==9963== -v
==9963== Reading suppressions file: /home/binaries/lib/valgrind/default.supp
==9963== Estimated CPU clock rate is 298 MHz
==9963==
==9963== Reading syms from /home/binaries/bin/tclsh8.4
==9963== Reading syms from /lib/ld-2.2.4.so
==9963== Reading syms from /home/binaries/lib/valgrind/vgskin_memcheck.so
==9963== Reading syms from /home/binaries/lib/valgrind/valgrind.so
==9963== Reading syms from /home/binaries/lib/libtcl8.4.so
==9963== Reading syms from /lib/libdl-2.2.4.so
==9963== Reading syms from /lib/i686/libm-2.2.4.so
==9963== Reading syms from /lib/i686/libc-2.2.4.so
==9963== Reading syms from /home/binaries/lib/libBLTlite24.so
==9963== object doesn't have any debug info
==9963== Reading syms from /home/binaries/lib/libspice.so
==9963== Reading syms from /usr/lib/libncurses.so.5.2
==9963== object doesn't have a symbol table
==9963== object doesn't have any debug info
==9963== Reading syms from /home/binaries/lib/valgrind/libpthread.so
==9963== Conditional jump or move depends on uninitialised value(s)
==9963== at 0x4036CA1F: strchr (in /lib/i686/libc-2.2.4.so)
==9963==
==9963== Invalid read of size 1
==9963== at 0x416D2F1E: ft_cpinit (cpitf.c:214)
==9963== by 0x416C9E45: Spice_Init (tclspice.c:1282)
==9963== by 0x40275B05: Tcl_LoadObjCmd (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40235668: TclEvalObjvInternal (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x402581B7: TclExecuteByteCode (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40257681: TclCompEvalObj (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40283DB7: TclObjInterpProc (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40235668: TclEvalObjvInternal (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40235FD0: Tcl_EvalEx (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x402363BC: Tcl_Eval (in /home/binaries/lib/libtcl8.4.so)
==9963== Address 0x4235C83C is 48 bytes inside a block of size 49 free'd
==9963== at 0x40169B6E: free (vg_clientfuncs.c:185)
==9963== by 0x416D2EC5: ft_cpinit (cpitf.c:219)
==9963== by 0x416C9E45: Spice_Init (tclspice.c:1282)
==9963== by 0x40275B05: Tcl_LoadObjCmd (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40235668: TclEvalObjvInternal (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x402581B7: TclExecuteByteCode (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40257681: TclCompEvalObj (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40283DB7: TclObjInterpProc (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40235668: TclEvalObjvInternal (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40235FD0: Tcl_EvalEx (in /home/binaries/lib/libtcl8.4.so)
==9963== Reading syms from /home/sources/tclspice-0.2.10-sdb/src/xspice/icm/spice2poly.cm
==9963== Reading syms from /usr/X11R6/lib/libX11.so.6.2
==9963== object doesn't have a symbol table
==9963== object doesn't have any debug info
==9963== Reading syms from /usr/X11R6/lib/libXt.so.6.0
==9963== object doesn't have a symbol table
==9963== object doesn't have any debug info
==9963== Reading syms from /usr/X11R6/lib/libXext.so.6.4
==9963== object doesn't have a symbol table
==9963== object doesn't have any debug info
==9963== Reading syms from /usr/X11R6/lib/libXmu.so.6.2
==9963== object doesn't have a symbol table
==9963== object doesn't have any debug info
==9963== Reading syms from /usr/X11R6/lib/libXaw.so.7.0
==9963== object doesn't have a symbol table
==9963== object doesn't have any debug info
==9963== Reading syms from /usr/X11R6/lib/libSM.so.6.0
==9963== object doesn't have a symbol table
==9963== object doesn't have any debug info
==9963== Reading syms from /usr/X11R6/lib/libICE.so.6.3
==9963== object doesn't have a symbol table
==9963== object doesn't have any debug info
==9963== Reading syms from /usr/X11R6/lib/libXpm.so.4.11
==9963== object doesn't have a symbol table
==9963== object doesn't have any debug info
==9963==
==9963== Conditional jump or move depends on uninitialised value(s)
==9963== at 0x4036CA64: strchr (in /lib/i686/libc-2.2.4.so)
==9963==
==9963== Invalid read of size 1
==9963== at 0x416C8483: _tcl_dispatch (tclspice.c:424)
==9963== by 0x402346A7: TclInvokeStringCommand (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40235668: TclEvalObjvInternal (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40235FD0: Tcl_EvalEx (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x402700F5: Tcl_FSEvalFile (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40276210: Tcl_Main (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x8048726: main (in /home/binaries/bin/tclsh8.4)
==9963== by 0x40303506: __libc_start_main (../sysdeps/generic/libc-start.c:129)
==9963== by 0x8048620: (within /home/binaries/bin/tclsh8.4)
==9963== Address 0x423EDD6C is 0 bytes after a block of size 12 alloc'd
==9963== at 0x40169890: malloc (vg_clientfuncs.c:103)
==9963== by 0x4023334D: TclpAlloc (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40239994: Tcl_Alloc (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x402878AF: Tcl_NewStringObj (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40235C8B: Tcl_EvalTokensStandard (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40235F45: Tcl_EvalEx (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x402700F5: Tcl_FSEvalFile (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40276210: Tcl_Main (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x8048726: main (in /home/binaries/bin/tclsh8.4)
==9963== by 0x40303506: __libc_start_main (../sysdeps/generic/libc-start.c:129)
==9963==
==9963== Invalid read of size 8
==9963== at 0x41812AB4: ISRCload (isrcload.c:174)
==9963== by 0x418A59F3: CKTload (cktload.c:69)
==9963== by 0x418C8EC2: NIiter (niiter.c:79)
==9963== by 0x418A10D0: DCtran (dctran.c:662)
==9963== by 0x41898F3B: CKTdoJob (cktdojob.c:160)
==9963== by 0x416E7B34: if_run (spiceif.c:313)
==9963== by 0x416E49F4: dosim (runcoms.c:267)
==9963== by 0x416E4646: com_tran (runcoms.c:135)
==9963== by 0x416CE3C4: docommand (control.c:200)
==9963== by 0x416CE89D: doblock (control.c:458)
==9963== Address 0x42DC5754 is 0 bytes after a block of size 144 alloc'd
==9963== at 0x40169E99: realloc (vg_clientfuncs.c:276)
==9963== by 0x418D09AD: trealloc (alloc.c:75)
==9963== by 0x418B4982: INPgetValue (inpgval.c:38)
==9963== by 0x418C0077: INPdevParse (inpdpar.c:55)
==9963== by 0x418BB039: INP2I (inp2i.c:54)
==9963== by 0x418B4DBC: INPpas2 (inppas2.c:154)
==9963== by 0x416E734E: if_inpdeck (spiceif.c:115)
==9963== by 0x416D9BBB: inp_dodeck (inp.c:586)
==9963== by 0x416D9A6B: inp_spsource (inp.c:497)
==9963== by 0x416DA2DD: com_source (inp.c:844)
==9963==
==9963== Invalid read of size 1
==9963== at 0x416C8483: _tcl_dispatch (tclspice.c:424)
==9963== by 0x402346A7: TclInvokeStringCommand (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40235668: TclEvalObjvInternal (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x402581B7: TclExecuteByteCode (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40257681: TclCompEvalObj (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40236526: Tcl_EvalObjEx (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x4023C0D3: Tcl_ForObjCmd (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40235668: TclEvalObjvInternal (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40235FD0: Tcl_EvalEx (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x402700F5: Tcl_FSEvalFile (in /home/binaries/lib/libtcl8.4.so)
==9963== Address 0x411B40B4 is 0 bytes after a block of size 12 alloc'd
==9963== at 0x40169890: malloc (vg_clientfuncs.c:103)
==9963== by 0x4023334D: TclpAlloc (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40239994: Tcl_Alloc (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40274DF8: TclRegisterLiteral (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x4024EA3D: TclCompileScript (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x4024FB80: TclCompileCmdWord (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40247694: TclCompileForCmd (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x4024E9FA: TclCompileScript (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x4024FB80: TclCompileCmdWord (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40247694: TclCompileForCmd (in /home/binaries/lib/libtcl8.4.so)
==9963==
==9963== ERROR SUMMARY: 2115 errors from 6 contexts (suppressed: 43111 from 3)
==9963==
==9963== 1 errors in context 1 of 6:
==9963== Invalid read of size 1
==9963== at 0x416C8483: _tcl_dispatch (tclspice.c:424)
==9963== by 0x402346A7: TclInvokeStringCommand (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40235668: TclEvalObjvInternal (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40235FD0: Tcl_EvalEx (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x402700F5: Tcl_FSEvalFile (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40276210: Tcl_Main (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x8048726: main (in /home/binaries/bin/tclsh8.4)
==9963== by 0x40303506: __libc_start_main (../sysdeps/generic/libc-start.c:129)
==9963== by 0x8048620: (within /home/binaries/bin/tclsh8.4)
==9963== Address 0x423EDD6C is 0 bytes after a block of size 12 alloc'd
==9963== at 0x40169890: malloc (vg_clientfuncs.c:103)
==9963== by 0x4023334D: TclpAlloc (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40239994: Tcl_Alloc (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x402878AF: Tcl_NewStringObj (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40235C8B: Tcl_EvalTokensStandard (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40235F45: Tcl_EvalEx (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x402700F5: Tcl_FSEvalFile (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40276210: Tcl_Main (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x8048726: main (in /home/binaries/bin/tclsh8.4)
==9963== by 0x40303506: __libc_start_main (../sysdeps/generic/libc-start.c:129)
==9963==
==9963== 1 errors in context 2 of 6:
==9963== Conditional jump or move depends on uninitialised value(s)
==9963== at 0x4036CA64: strchr (in /lib/i686/libc-2.2.4.so)
==9963==
==9963== 1 errors in context 3 of 6:
==9963== Invalid read of size 1
==9963== at 0x416D2F1E: ft_cpinit (cpitf.c:214)
==9963== by 0x416C9E45: Spice_Init (tclspice.c:1282)
==9963== by 0x40275B05: Tcl_LoadObjCmd (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40235668: TclEvalObjvInternal (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x402581B7: TclExecuteByteCode (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40257681: TclCompEvalObj (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40283DB7: TclObjInterpProc (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40235668: TclEvalObjvInternal (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40235FD0: Tcl_EvalEx (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x402363BC: Tcl_Eval (in /home/binaries/lib/libtcl8.4.so)
==9963== Address 0x4235C83C is 48 bytes inside a block of size 49 free'd
==9963== at 0x40169B6E: free (vg_clientfuncs.c:185)
==9963== by 0x416D2EC5: ft_cpinit (cpitf.c:219)
==9963== by 0x416C9E45: Spice_Init (tclspice.c:1282)
==9963== by 0x40275B05: Tcl_LoadObjCmd (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40235668: TclEvalObjvInternal (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x402581B7: TclExecuteByteCode (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40257681: TclCompEvalObj (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40283DB7: TclObjInterpProc (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40235668: TclEvalObjvInternal (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40235FD0: Tcl_EvalEx (in /home/binaries/lib/libtcl8.4.so)
==9963==
==9963== 4 errors in context 4 of 6:
==9963== Invalid read of size 1
==9963== at 0x416C8483: _tcl_dispatch (tclspice.c:424)
==9963== by 0x402346A7: TclInvokeStringCommand (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40235668: TclEvalObjvInternal (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x402581B7: TclExecuteByteCode (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40257681: TclCompEvalObj (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40236526: Tcl_EvalObjEx (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x4023C0D3: Tcl_ForObjCmd (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40235668: TclEvalObjvInternal (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40235FD0: Tcl_EvalEx (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x402700F5: Tcl_FSEvalFile (in /home/binaries/lib/libtcl8.4.so)
==9963== Address 0x411B40B4 is 0 bytes after a block of size 12 alloc'd
==9963== at 0x40169890: malloc (vg_clientfuncs.c:103)
==9963== by 0x4023334D: TclpAlloc (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40239994: Tcl_Alloc (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40274DF8: TclRegisterLiteral (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x4024EA3D: TclCompileScript (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x4024FB80: TclCompileCmdWord (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40247694: TclCompileForCmd (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x4024E9FA: TclCompileScript (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x4024FB80: TclCompileCmdWord (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40247694: TclCompileForCmd (in /home/binaries/lib/libtcl8.4.so)
==9963==
==9963== 5 errors in context 5 of 6:
==9963== Conditional jump or move depends on uninitialised value(s)
==9963== at 0x4036CA1F: strchr (in /lib/i686/libc-2.2.4.so)
==9963==
==9963== 2103 errors in context 6 of 6:
==9963== Invalid read of size 8
==9963== at 0x41812AB4: ISRCload (isrcload.c:174)
==9963== by 0x418A59F3: CKTload (cktload.c:69)
==9963== by 0x418C8EC2: NIiter (niiter.c:79)
==9963== by 0x418A10D0: DCtran (dctran.c:662)
==9963== by 0x41898F3B: CKTdoJob (cktdojob.c:160)
==9963== by 0x416E7B34: if_run (spiceif.c:313)
==9963== by 0x416E49F4: dosim (runcoms.c:267)
==9963== by 0x416E4646: com_tran (runcoms.c:135)
==9963== by 0x416CE3C4: docommand (control.c:200)
==9963== by 0x416CE89D: doblock (control.c:458)
==9963== Address 0x42DC5754 is 0 bytes after a block of size 144 alloc'd
==9963== at 0x40169E99: realloc (vg_clientfuncs.c:276)
==9963== by 0x418D09AD: trealloc (alloc.c:75)
==9963== by 0x418B4982: INPgetValue (inpgval.c:38)
==9963== by 0x418C0077: INPdevParse (inpdpar.c:55)
==9963== by 0x418BB039: INP2I (inp2i.c:54)
==9963== by 0x418B4DBC: INPpas2 (inppas2.c:154)
==9963== by 0x416E734E: if_inpdeck (spiceif.c:115)
==9963== by 0x416D9BBB: inp_dodeck (inp.c:586)
==9963== by 0x416D9A6B: inp_spsource (inp.c:497)
==9963== by 0x416DA2DD: com_source (inp.c:844)
--9963--
--9963-- supp: 85 _dl_relocate_object/libc-2.2.4.so/_dl_catch_error(Cond)
--9963-- supp: 14342 __mpn_construct_double/*(Addr8)
--9963-- supp: 28684 __mpn_construct_double/*(Addr4)
==9963==
==9963== IN SUMMARY: 2115 errors from 6 contexts (suppressed: 43111 from 3)
==9963==
==9963== malloc/free: in use at exit: 8455983 bytes in 26988 blocks.
==9963== malloc/free: 2408648 allocs, 2381660 frees, 1846607616 bytes allocated.
==9963==
==9963== searching for pointers to 26988 not-freed blocks.
==9963== checked 18436024 bytes.
==9963==
==9963== 776 bytes in 39 blocks are definitely lost in loss record 11 of 21
==9963== at 0x40169E99: realloc (vg_clientfuncs.c:276)
==9963== by 0x418D09AD: trealloc (alloc.c:75)
==9963== by 0x416FB2D6: MIFgetValue (mifgetvalue.c:190)
==9963== by 0x416FAE93: MIFgetMod (mifgetmod.c:205)
==9963== by 0x416FA043: MIF_INP2A (mif_inp2.c:190)
==9963== by 0x418B4CDC: INPpas2 (inppas2.c:73)
==9963== by 0x416E734E: if_inpdeck (spiceif.c:115)
==9963== by 0x416D9BBB: inp_dodeck (inp.c:586)
==9963== by 0x416D9A6B: inp_spsource (inp.c:497)
==9963== by 0x416DA2DD: com_source (inp.c:844)
==9963==
==9963== 1498 bytes in 10 blocks are possibly lost in loss record 13 of 21
==9963== at 0x40169D7D: calloc (vg_clientfuncs.c:245)
==9963== by 0x418D093E: tmalloc (alloc.c:41)
==9963== by 0x418D0CD7: copy (string.c:37)
==9963== by 0x418D0F8C: gettok (string.c:159)
==9963== by 0x416EC463: devmodtranslate (subckt.c:1305)
==9963== by 0x416EAF7A: doit (subckt.c:390)
==9963== by 0x416EAB01: inp_subcktexpand (subckt.c:168)
==9963== by 0x416D99E0: inp_spsource (inp.c:476)
==9963== by 0x416DA2DD: com_source (inp.c:844)
==9963== by 0x416CE3C4: docommand (control.c:200)
==9963==
==9963== 8000 bytes in 1 blocks are possibly lost in loss record 16 of 21
==9963== at 0x40169890: malloc (vg_clientfuncs.c:103)
==9963== by 0x4023334D: TclpAlloc (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40239994: Tcl_Alloc (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40256DE8: TclCreateExecEnv (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x4023379A: Tcl_CreateInterp (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x40275FEE: Tcl_Main (in /home/binaries/lib/libtcl8.4.so)
==9963== by 0x8048726: main (in /home/binaries/bin/tclsh8.4)
==9963== by 0x40303506: __libc_start_main (../sysdeps/generic/libc-start.c:129)
==9963== by 0x8048620: (within /home/binaries/bin/tclsh8.4)
==9963==
==9963== 42027 bytes in 6180 blocks are definitely lost in loss record 17 of 21
==9963== at 0x40169D7D: calloc (vg_clientfuncs.c:245)
==9963== by 0x418D093E: tmalloc (alloc.c:41)
==9963== by 0x418D0CD7: copy (string.c:37)
==9963== by 0x418B14FC: cp_addkword (complete.c:521)
==9963== by 0x416ED9F0: plot_alloc (vectors.c:521)
==9963== by 0x416DE7A2: plotInit (outitf.c:898)
==9963== by 0x416DD9A9: beginPlot (outitf.c:359)
==9963== by 0x416DCE43: OUTpBeginPlot (outitf.c:99)
==9963== by 0x418A040C: DCtran (dctran.c:125)
==9963== by 0x41898F3B: CKTdoJob (cktdojob.c:160)
==9963==
==9963== LEAK SUMMARY:
==9963== definitely lost: 42803 bytes in 6219 blocks.
==9963== possibly lost: 9498 bytes in 11 blocks.
==9963== still reachable: 8403682 bytes in 20758 blocks.
==9963== suppressed: 0 bytes in 0 blocks.
==9963== Reachable blocks (those to which a pointer was found) are not shown.
==9963== To see them, rerun with: --show-reachable=yes
==9963==
--9963-- TT/TC: 0 tc sectors discarded.
--9963-- 20172 chainings, 0 unchainings.
--9963-- translate: new 22817 (363930 -> 5141044; ratio 141:10)
--9963-- discard 0 (0 -> 0; ratio 0:10).
--9963-- dispatch: 657100000 jumps (bb entries), of which 58495173 (8%) were unchained.
--9963-- 13144/7746532 major/minor sched events. 80903 tt_fast misses.
--9963-- reg-alloc: 3748 t-req-spill, 947035+21492 orig+spill uis, 116390 total-reg-r.
--9963-- sanity: 13145 cheap, 526 expensive checks.
--9963-- ccalls: 111426 C calls, 54% saves+restores avoided (358866 bytes)
--9963-- 145920 args, avg 0.87 setup instrs each (37630 bytes)
--9963-- 0% clear the stack (334278 bytes)
--9963-- 39149 retvals, 31% of reg-reg movs avoided (23654 bytes)
------------------- end valgrind log ---------------------------
3. Rather than try fixing the memory leak problem, I have developed a
work-around. It is an ugly hack, but it allows me to acheive my
goal of doing circuit optimizations. I have written my optimizer
to save its state into a file after every analysis. When the
optimizer starts up, it reads the last state from the file, and
starts doing the analysis from that point. The optimizer program
also stores the best circuit parameters found so far into another
file, and also reads these into the program when starting up.
Then, I have a wrapper TCL program called TaskMgr.tcl, which forks
a child process to run the optimizer. After the fork, the parent
waits for 5 minutes (which I have learned is long enough for
tclspice to eat a significant amout of memoery). After 5 minutes,
the parent issues a "kill" signal to the child, and then restarts
it. This way, the child never grows to the point where it has
eaten all memory. Since its state is always saved, the
optimization can always start up from the last computed state, and
my optimization can crank along for hours and days, despite the
memory leak.
In the spirit of sharing, I reproduce my hack program TaskMgr.tcl
below. There's nothing special about it; anybody else could also
write it, but since I have already done it, I hope that others
can use it and avoid re-inventing the wheel.
Two notes about TaskMgr.tcl:
1. You will need to tune the amount of time to wait to meet the
memory size and processor speed of your system. I have set
mine to kill the child after 300,000 ms = 5 minutes. You can
determine this time for your system experimentally.
2. Note that you need to do the "wait $PID" after doing "kill
$PID" because if you don't do the wait, you are left with
zombie processes hanging around (yuk!).
------------------- begin TaskMgr.tcl ---------------------------
#! tclsh
package require Tclx
while {1} {
set PID [fork]
if {$PID} {
# Parent
after 300000
puts "About to kill child PID = $PID . . . ."
kill $PID
wait $PID
} else {
# Child
source Optimize.tcl
# If we ever get through this, we can print out the following:
error "We are done now!!!!!!"
}
}
------------------- end TaskMgr.tcl ---------------------------
4. Stefan, I have a suggestion: It would be nice if the analysis
functions like "spice::tran" or "spice::ac" returned a return code
like "0 = success, 1 = failure", or something. This is desirable
because sometimes the SPICE analysis fails due to non-convergence,
and there is no way to detect this directly. Instead, you have to
figure it out indirectly because the plot vectors are all of
length 0.
I would be happy to implement this improvement myself, but I am
not familiar enough with the analysis code to be able to implement
this. If somebody has a pointer or two, I could try it . . . .
That's it for now. Again, thank you to everybody involved for their
excellent work on tclspice and ngspice. They are great applications!
Stuart
[1] Valgrind is an excellent memory leak debug tool. Information is
available at http://developer.kde.org/~sewardj/
|
