Something is *very* wrong in that stack trace; it definitely looks like stack
corruption.
The evidence is that TclEvalObjvInternal is called with objc=3 (frame 7), and it
then calls Tcl_LoadObjCmd with objc=0. But objc is passed untouched by
TclEvalObjvInternal.
Petr Salinger wrote:
Threaded tclsh8.5 segfaults on exit after loading any shared library
using [load] command. In your case it was libdb_tcl-4.6.so (Tcl
interface to BDB).
Unfortunately, it seems that the stack is corrupted during the crash,
so GDB isn't informative. It gives something like the following (and
never shows the symbols):
Both GNU/Linux and FreeBSD work fine. So, it seems to be a problem
with working with threads using glibc and kfreebsd. It seems to me that
Tcl developers don't use so unusual environment, but I'll ask them
anyway.
Thanks for the hint.
I added "--enable-symbols" to debian/rules, build package and
cd unix
ln -sf libtcl8.5.so libtcl8.5.so.0
LD_LIBRARY_PATH=${PWD} ./tclsh ../tests/load.test
gdb tclsh tclsh.core
The output of gdb is attached (from kfreebsd-amd64).
Unfortunately, I do not speak tcl, so I cannot reduce testcase
or see what is wrong.
GNU/kFreeBSD uses same kernel as FreeBSD and
glibc as linux, but it still uses linuxthreads (not NPTL).
But linuxthreads is still used on hppa, please could you (as DD)
test whether it does have same problem ?
Testsuite in db is on hppa disabled, so a problem with "load" would not
lead to FTBFS of db/db4.6 on hppa.
Thanks for your care about GNU/kFreeBSD.
Petr
------------------------------------------------------------------------
_______________________________________________
Pkg-tcltk-devel mailing list
[EMAIL PROTECTED]
http://lists.alioth.debian.org/mailman/listinfo/pkg-tcltk-devel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
