Hi,
I have just re-installed Xotcl 1.0.2 version and succedeed in running my application with some minor changes since the last xotcl version I used on this platform (Sparc/Solaris 7) was the 0.9 :-)
I have a segmentation fault that occurs when a command is called from a Tk menu. The command is attached to the popup by a: add command -command statement on a menu Tk widget that is raised by a tk_popup.
However, the very same command, when called from the tcl (xowish) interpreter, works and does not produce any core dump. And most menu items also work well.
So my question is: how do I debug such a situation? Thanks for any help...
On Friday 29 August 2003 16:26, Catherine Letondal wrote:
Hi,
I have just re-installed Xotcl 1.0.2 version and succedeed in running my application with some minor changes since the last xotcl version I used on this platform (Sparc/Solaris 7) was the 0.9 :-)
I have a segmentation fault that occurs when a command is called from a Tk menu. The command is attached to the popup by a: add command -command statement on a menu Tk widget that is raised by a tk_popup.
However, the very same command, when called from the tcl (xowish) interpreter, works and does not produce any core dump. And most menu items also work well.
So my question is: how do I debug such a situation? Thanks for any help...
You should compile wish with symbols (./configure --enable-symbols). The same appiles for xotcl as well. Then just say:
gdb wish <some gdb output> (gdb) run
This will start the wish. You can put some arguments to the run command, the same ones you'd normally pass to wish:
(gdb) run myscript.tcl
Then just run the code. On segv, the debugger will pop-up and you can then do
(gdb) bt
which stands for "backtrace". This will show the stack. This is very helpful in diagnosing problems.
Of course, you need a gdb debugger for Sun. I think there are lots of sites on the net offering precompiled binaries for solaris.
When you have the backtrace, just post it to the list and we'll see what happens.
Cheers Zoran
Zoran Vasiljevic wrote:
On Friday 29 August 2003 16:26, Catherine Letondal wrote:
Hi,
I have just re-installed Xotcl 1.0.2 version and succedeed in running my application with some minor changes since the last xotcl version I used on this platform (Sparc/Solaris 7) was the 0.9 :-)
I have a segmentation fault that occurs when a command is called from a Tk menu. The command is attached to the popup by a: add command -command statement on a menu Tk widget that is raised by a tk_popup.
However, the very same command, when called from the tcl (xowish) interpreter, works and does not produce any core dump. And most menu items also work well.
So my question is: how do I debug such a situation? Thanks for any help...
You should compile wish with symbols (./configure --enable-symbols). The same appiles for xotcl as well.
When I compile xotcl after a ./configure --enable-symbols the compilation just fails to compile because it looks for a libtcl8.3g.so file (or maybe I should have built the tcl library before?):
cc -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DVERSION="1.0" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_UNISTD_H=1 -DHAVE_TCL_COMPILE_H=1 -DTCL_SHLIB_EXT=".so" -I/local/packages/tcl8.3.2/generic -I/local/packages/tcl8.3.2/unix -I"./../generic" -I"./../unix" -I"/usr/local/include" -g -g -fPIC -g -DXOLIBPKG="/usr/local/lib/xotcl1.0" -DXOTCLVERSION="1.0" -DXOTCLPATCHLEVEL=".2" -c `echo ../unix/xotclAppInit.c` -o o/xotclAppInit.o cc: Warning: illegal option -fPIC cc -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DVERSION="1.0" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_UNISTD_H=1 -DHAVE_TCL_COMPILE_H=1 -DTCL_SHLIB_EXT=".so" -I/local/packages/tcl8.3.2/generic -I/local/packages/tcl8.3.2/unix -I"./../generic" -I"./../unix" -I"/usr/local/include" -g -g -fPIC -g -DXOLIBPKG="/usr/local/lib/xotcl1.0" -DXOTCLVERSION="1.0" -DXOTCLPATCHLEVEL=".2" -c `echo ../generic/findXOTcl.c` -o o/findXOTcl.o cc: Warning: illegal option -fPIC cc o/xotclAppInit.o o/findXOTcl.o -L/local/packages/tcl8.3.2/unix -ltcl8.3g -ldl -lsocket -lnsl -lm -lc -o ../xotclsh ld: fatal: library -ltcl8.3g: not found ld: fatal: File processing errors. No output written to ../xotclsh *** Error code 1 make: Fatal error: Command failed for target `../xotclsh' Current working directory /local/packages/xotcl-1.0.2/unix *** Error code 1 make: Fatal error: Command failed for target `xotclsh'
But in fact, gdb tells where the program stopped:
(gdb) bt #0 0xfed5c580 in Tcl_PopCallFrame () from /local/lib/libtcl8.3.so #1 0xfed69950 in TclObjInterpProc () from /local/lib/libtcl8.3.so #2 0xfed61f98 in EvalObjv () from /local/lib/libtcl8.3.so #3 0xfed625dc in Tcl_EvalEx () from /local/lib/libtcl8.3.so #4 0xfed627cc in Tcl_Eval () from /local/lib/libtcl8.3.so #5 0xfed28114 in Tcl_GlobalEval () from /local/lib/libtcl8.3.so #6 0xfee26058 in Tk_BindEvent () from /local/lib/libtk8.3.so #7 0xfee2aaac in TkBindEventProc () from /local/lib/libtk8.3.so #8 0xfee308a0 in Tk_HandleEvent () from /local/lib/libtk8.3.so #9 0xfee30ca4 in WindowEventProc () from /local/lib/libtk8.3.so #10 0xfed5f960 in Tcl_ServiceEvent () from /local/lib/libtcl8.3.so #11 0xfed5fcf8 in Tcl_DoOneEvent () from /local/lib/libtcl8.3.so #12 0xfee30d08 in Tk_MainLoop () from /local/lib/libtk8.3.so #13 0xfee3bb7c in Tk_MainEx () from /local/lib/libtk8.3.so #14 0x2be9c in main ()
In fact I should rather re-start from the beginning. I had many problems during the compilation of Xotcl on my platform. Here is how the output looks like:
Text relocation remains referenced against symbol offset in file <unknown> 0x140f8 so/xotcl.o <unknown> 0x140f4 so/xotcl.o <unknown> 0x13d78 so/xotcl.o <unknown> 0x10b60 so/xotcl.o <unknown> 0x13644 so/xotcl.o <unknown> 0x10b5c so/xotcl.o [...] memcpy 0x50 so/xotcl.o memcpy 0x124 so/xotcl.o memcpy 0x638 so/xotcl.o memcpy 0xf594 so/xotcl.o memcpy 0x5a4 so/xotcl.o memcpy 0xbc so/xotcl.o tclStubsPtr 0x96a8 so/xotcl.o tclStubsPtr 0x98ac so/xotcl.o tclStubsPtr 0x98dc so/xotcl.o tclStubsPtr 0x98e0 so/xotcl.o tclStubsPtr 0x9680 so/xotcl.o tclStubsPtr 0x9600 so/xotcl.o [...] tclStubsPtr 0x468 so/xotclTrace.o [...] XOTclObjErrArgCnt 0xd2f8 so/xotcl.o [...] XOTclObjErrArgCnt 0x12dac so/xotcl.o [...] XOTclObjErrArgCnt 0x458 so/xotclTrace.o [...] tclIntStubsPtr 0x119dc so/xotcl.o [...] XOTclAddPMethod 0x10ad8 so/xotcl.o XOTclAddPMethod 0x1447c so/xotcl.o XOTclSelfDispatchCmd 0x1443c so/xotcl.o XOTclSelfDispatchCmd 0x14438 so/xotcl.o XOTclInitProcNSCmd 0x14414 so/xotcl.o XOTclInitProcNSCmd 0x14418 so/xotcl.o Xotcl_Init 0x12f40 so/xotcl.o Tcl_InitStubs 0x138f0 so/xotcl.o XOTcl_TraceObjCmd 0x14388 so/xotcl.o XOTcl_TraceObjCmd 0x14384 so/xotcl.o <unknown> 0xa4 so/xotclError.o <unknown> 0xc0 so/xotclError.o <unknown> 0x114 so/xotclError.o [...]
XOTclStackTrace 0x498 so/xotclTrace.o XOTclCallStackTrace 0x4c0 so/xotclTrace.o ld: fatal: relocations remain against allocatable but non-writable sections make: Fatal error: Command failed for target `libxotcl1.0.so' Current working directory /local/packages/xotcl-1.0.2/unix make: Fatal error: Command failed for target `libs'
I don't remember how it is I still have a libxotcl1.o.so built!!
No wonder there is a segmentation fault.
Thanks a lot for any help,
-- Catherine Letondal -- Pasteur Institute Computing Center
On Monday 01 September 2003 11:56, Catherine Letondal wrote:
You should compile wish with symbols (./configure --enable-symbols). The same appiles for xotcl as well.
When I compile xotcl after a ./configure --enable-symbols the compilation just fails to compile because it looks for a libtcl8.3g.so file (or maybe I should have built the tcl library before?):
Of course, you need to compile Tcl with --enable-symbols. This will produce the libtcl8.3g.so library.
I don't remember how it is I still have a libxotcl1.o.so built!!
No wonder there is a segmentation fault.
Thanks a lot for any help,
No problem. Just get a clean compilation of xotcl first. If the problems persist, then recompile all with --enable-symbols and give it another try.
Cheers, Zoran
Zoran Vasiljevic wrote:
On Monday 01 September 2003 11:56, Catherine Letondal wrote:
You should compile wish with symbols (./configure --enable-symbols). The same appiles for xotcl as well.
When I compile xotcl after a ./configure --enable-symbols the compilation just fails to compile because it looks for a libtcl8.3g.so file (or maybe I should have built the tcl library before?):
Of course, you need to compile Tcl with --enable-symbols. This will produce the libtcl8.3g.so library.
I don't remember how it is I still have a libxotcl1.o.so built!!
No wonder there is a segmentation fault.
Thanks a lot for any help,
No problem. Just get a clean compilation of xotcl first. If the problems persist, then recompile all with --enable-symbols and give it another try.
Ok: everything is recompiled with --enable-symbols and the compilation of Xotcl went without pbs. I still have the seg fault:
% gdb ~/Work/TclTk/proto/mywish2/mywish core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.7"... Core was generated by `/home/letondal/Work/TclTk/proto/mywish2/mywish'. Program terminated with signal 9, Killed. Reading symbols from /local/lib/libGLU.so.1...done. Reading symbols from /local/lib/libGL.so.1...done. Reading symbols from /local/lib/libglut.so.3...done. Reading symbols from /home/letondal/packages/seqiotcl/seqiotcl.so...done. Reading symbols from /local/lib/libxotcl1.0g.so...done. Reading symbols from /local/lib/libtk8.3.so...done. Reading symbols from /local/lib/libtcl8.3g.so...done. Reading symbols from /usr/lib/libX11.so.4...done. Reading symbols from /usr/lib/libm.so.1...done. Reading symbols from /usr/lib/libc.so.1...done. Reading symbols from /usr/openwin/lib/libSM.so.6...done. Reading symbols from /usr/openwin/lib/libICE.so.6...done. Reading symbols from /usr/openwin/lib/libXmu.so.4...done. Reading symbols from /usr/openwin/lib/libXext.so.0...done. Reading symbols from /usr/openwin/lib/libXi.so.5...done. Reading symbols from /usr/lib/libpthread.so.1...done. Reading symbols from /local/lib/libtcl8.2.so...done. Reading symbols from /usr/lib/libsocket.so.1...done. Reading symbols from /usr/lib/libnsl.so.1...done. Reading symbols from /usr/lib/libdl.so.1...done. Reading symbols from /usr/openwin/lib/libXt.so.4...done. ---Type <return> to continue, or q <return> to quit--- Reading symbols from /usr/lib/libmp.so.2...done. Reading symbols from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1...done. Reading symbols from /usr/lib/libthread.so.1...done. Reading symbols from /home/letondal/Work/TclTk/proto/iMol/iMol.so...done. Reading symbols from /home/letondal/Work/TclTk/proto/i3DMol/lib/i3D.so...done. #0 Tcl_PopCallFrame (interp=0x19c380) at ./../generic/tclNamesp.c:359 359 iPtr->framePtr = framePtr->callerPtr; (gdb) l 354 * of call frames before deleting local variables, so that traces 355 * invoked by the variable deletion don't see the partially-deleted 356 * frame. 357 */ 358 359 iPtr->framePtr = framePtr->callerPtr; 360 iPtr->varFramePtr = framePtr->callerVarPtr; 361 362 /* 363 * Delete the local variables. As a hack, we save then restore the
Any idea about the problem?
Thanks a lot in advance,
-- Catherine Letondal
Catherine Letondal wrote:
Zoran Vasiljevic wrote:
On Friday 29 August 2003 16:26, Catherine Letondal wrote:
Hi,
I have just re-installed Xotcl 1.0.2 version and succedeed in running my application with some minor changes since the last xotcl version I used on this platform (Sparc/Solaris 7) was the 0.9 :-)
I have a segmentation fault that occurs when a command is called from a Tk menu. The command is attached to the popup by a: add command -command statement on a menu Tk widget that is raised by a tk_popup.
However, the very same command, when called from the tcl (xowish) interpreter, works and does not produce any core dump. And most menu items also work well.
So my question is: how do I debug such a situation? Thanks for any help...
It seems that I have subscribed to this problem :-) This time it is on a debian/linux (an old one) where xotcl 1.0.2 was successfully compiled (although make test hangs, I don't know why).
It's the same symptom: A Tk window built by a command either is correctly displayed if the command is called directly from the "wish", or causes a seg fault if the command is called from a Tk menu. I have compiled xotcl/tcl/tk/itk/itcl with --enable-symbols (I haven't recompiled other libraries such as blt though). Unfortunately, my gdb is broken - but since the symptom is the same, here is the report of gdb for the last time it happended (it was tcl 8.3 and now it is 8.4):
#0 0xfed5c580 in Tcl_PopCallFrame () from /local/lib/libtcl8.3.so #1 0xfed69950 in TclObjInterpProc () from /local/lib/libtcl8.3.so #2 0xfed61f98 in EvalObjv () from /local/lib/libtcl8.3.so #3 0xfed625dc in Tcl_EvalEx () from /local/lib/libtcl8.3.so #4 0xfed627cc in Tcl_Eval () from /local/lib/libtcl8.3.so #5 0xfed28114 in Tcl_GlobalEval () from /local/lib/libtcl8.3.so #6 0xfee26058 in Tk_BindEvent () from /local/lib/libtk8.3.so #7 0xfee2aaac in TkBindEventProc () from /local/lib/libtk8.3.so #8 0xfee308a0 in Tk_HandleEvent () from /local/lib/libtk8.3.so #9 0xfee30ca4 in WindowEventProc () from /local/lib/libtk8.3.so #10 0xfed5f960 in Tcl_ServiceEvent () from /local/lib/libtcl8.3.so #11 0xfed5fcf8 in Tcl_DoOneEvent () from /local/lib/libtcl8.3.so #12 0xfee30d08 in Tk_MainLoop () from /local/lib/libtk8.3.so #13 0xfee3bb7c in Tk_MainEx () from /local/lib/libtk8.3.so #14 0x2be9c in main ()
So, if anyone has an idea of why this happens everytime I reinstall xotcl... :-(
Thanks in advance,
-- Catherine Letondal -- Pasteur Institute Computing Center
It seems that I have subscribed to this problem :-) This time it is on a debian/linux (an old one) where xotcl 1.0.2 was successfully compiled (although make test hangs, I don't know why).
It's the same symptom: A Tk window built by a command either is correctly displayed if the command is called directly from the "wish", or causes a seg fault if the command is called from a Tk menu. I have compiled xotcl/tcl/tk/itk/itcl with --enable-symbols (I haven't recompiled other libraries such as blt though). Unfortunately, my gdb is broken - but since the symptom is the same, here is the report
of gdb for the last time it happended (it was tcl 8.3 and now it is 8.4):
#0 0xfed5c580 in Tcl_PopCallFrame () from /local/lib/libtcl8.3.so #1 0xfed69950 in TclObjInterpProc () from /local/lib/libtcl8.3.so #2 0xfed61f98 in EvalObjv () from /local/lib/libtcl8.3.so #3 0xfed625dc in Tcl_EvalEx () from /local/lib/libtcl8.3.so #4 0xfed627cc in Tcl_Eval () from /local/lib/libtcl8.3.so #5 0xfed28114 in Tcl_GlobalEval () from /local/lib/libtcl8.3.so #6 0xfee26058 in Tk_BindEvent () from /local/lib/libtk8.3.so #7 0xfee2aaac in TkBindEventProc () from /local/lib/libtk8.3.so #8 0xfee308a0 in Tk_HandleEvent () from /local/lib/libtk8.3.so #9 0xfee30ca4 in WindowEventProc () from /local/lib/libtk8.3.so #10 0xfed5f960 in Tcl_ServiceEvent () from /local/lib/libtcl8.3.so #11 0xfed5fcf8 in Tcl_DoOneEvent () from /local/lib/libtcl8.3.so #12 0xfee30d08 in Tk_MainLoop () from /local/lib/libtk8.3.so #13 0xfee3bb7c in Tk_MainEx () from /local/lib/libtk8.3.so #14 0x2be9c in main ()
So, if anyone has an idea of why this happens everytime I reinstall xotcl... :-(
The same stack dump I have got with 1.1.1. I used also callbacks from Tk. I could find out that it crashed in context of additional instmixinst but only by 1.1.1 Herr Neumann send me pre realease of 1.1.2 with some explanation. In Version 1.1.1 the insmixins treads the frame in same way as filters in pre 1.1.1. With 1.1.2 it do not crash any more but I do not know if the problem was fixed or the instmixinst works as in 1.0.2.
Do you use filters in context of Tk callback? If yes, you can try to remove temporary the filters and look if the crash happen.
Artur Trzewik
Artur Trzewik wrote:
It seems that I have subscribed to this problem :-) This time it is on a debian/linux (an old one) where xotcl 1.0.2 was successfully compiled (although make test hangs, I don't know why).
It's the same symptom: A Tk window built by a command either is correctly displayed if the command is called directly from the "wish", or causes a seg fault if the command is called from a Tk menu. I have compiled xotcl/tcl/tk/itk/itcl with --enable-symbols (I haven't recompiled other libraries such as blt though). Unfortunately, my gdb is broken - but since the symptom is the same, here is the report
of gdb for the last time it happended (it was tcl 8.3 and now it is 8.4):
#0 0xfed5c580 in Tcl_PopCallFrame () from /local/lib/libtcl8.3.so #1 0xfed69950 in TclObjInterpProc () from /local/lib/libtcl8.3.so #2 0xfed61f98 in EvalObjv () from /local/lib/libtcl8.3.so #3 0xfed625dc in Tcl_EvalEx () from /local/lib/libtcl8.3.so #4 0xfed627cc in Tcl_Eval () from /local/lib/libtcl8.3.so #5 0xfed28114 in Tcl_GlobalEval () from /local/lib/libtcl8.3.so #6 0xfee26058 in Tk_BindEvent () from /local/lib/libtk8.3.so #7 0xfee2aaac in TkBindEventProc () from /local/lib/libtk8.3.so #8 0xfee308a0 in Tk_HandleEvent () from /local/lib/libtk8.3.so #9 0xfee30ca4 in WindowEventProc () from /local/lib/libtk8.3.so #10 0xfed5f960 in Tcl_ServiceEvent () from /local/lib/libtcl8.3.so #11 0xfed5fcf8 in Tcl_DoOneEvent () from /local/lib/libtcl8.3.so #12 0xfee30d08 in Tk_MainLoop () from /local/lib/libtk8.3.so #13 0xfee3bb7c in Tk_MainEx () from /local/lib/libtk8.3.so #14 0x2be9c in main ()
So, if anyone has an idea of why this happens everytime I reinstall xotcl... :-(
The same stack dump I have got with 1.1.1. I used also callbacks from Tk. I could find out that it crashed in context of additional instmixinst but onl
y
by 1.1.1 Herr Neumann send me pre realease of 1.1.2 with some explanation. In Version 1.1.1 the insmixins treads the frame in same way as filters in pre
1.1.1. With 1.1.2 it do not crash any more but I do not know if the problem was fixed or the instmixinst works as in 1.0.2.
Do you use filters in context of Tk callback? If yes, you can try to remove temporary the filters and look if the crash happen.
No, no filters are active when it happens.
-- Catherine Letondal -- Pasteur Institute Computing Center
-
Artur Trzewik -
Catherine Letondal -
Zoran Vasiljevic