Itk - the [incr Tk] extension

This script crashes most of the time:

package require Itk 4.1
package require Iwidgets 4.1

while 1 {
iwidgets::Buttonbox .bb

.bb add Yes -text Yes
.bb configure -highlightthickness 2
catch {.bb add Maybe -text Maybe} msg

destroy .bb
}

turn on mem debugging and get...

Program received signal SIGSEGV, Segmentation fault.
0x00000000005f9edc in BgErrorDeleteProc (clientData=0x6161616100000493, interp=0x0)
    at /home/dgp/fossil/tcl8.6.7/generic/tclEvent.c:602
602         while (assocPtr->firstBgPtr != NULL) {
Missing separate debuginfos, use: debuginfo-install expat-2.1.0-10.el7_3.x86_64 fontconfig-2.10.95-10.el7.x86_64 freetype-2.4.11-12.el7.x86_64 glibc-2.17-157.el7_3.4.x86_64 libX11-1.6.3-3.el7.x86_64 libXScrnSaver-1.2.2-6.1.el7.x86_64 libXau-1.0.8-2.1.el7.x86_64 libXcursor-1.1.14-2.1.el7.x86_64 libXext-1.3.3-3.el7.x86_64 libXfixes-5.0.1-2.1.el7.x86_64 libXft-2.3.2-2.el7.x86_64 libXrender-0.9.8-2.1.el7.x86_64 libxcb-1.11-4.el7.x86_64 zlib-1.2.7-17.el7.x86_64
(gdb) bt
#0  0x00000000005f9edc in BgErrorDeleteProc (clientData=0x6161616100000493, interp=0x0)
    at /home/dgp/fossil/tcl8.6.7/generic/tclEvent.c:602
#1  0x00007fffee8a7132 in Itk_DelOptionPart (optPart=0x1320458) at ./generic/itkArchBase.c:2551
#2  0x00007fffee8a696b in Itk_DelArchOption (archOpt=0x12f8c78) at ./generic/itkArchBase.c:2165
#3  0x00007fffee8a23a9 in Itk_DelArchInfo (cdata=0xfce868) at ./generic/itkArchBase.c:141
#4  0x00007fffee8a8647 in Itk_ArchDeleteOptsCmd (dummy=0x0, interp=0x975b28, objc=1, objv=0xf54d48)
    at ./generic/itkArchetype.c:381


(gdb) print *optPart
$2 = {clientData = 0x6161616100000493, configProc = 0x6161616161616161, deleteProc = 0x5f9e53 <BgErrorDeleteProc>, 
  from = 0x13870d8}

So at least some strange memory corruption at work

Also not clear to me how BgErrorDeleteProc gets
in there.

Problem was in Itk_AddOptionPart().

The routine always added the ArchOptionPart
to a list.  Then it tested access and configuration
matters, and if they failed, returned TCL_ERROR
without removing from the list.  The caller would
then free the optProc and later tearing down the
list would free it again.

Double free of memory leads to great evil.

fix committed