Tcl Source Code

Observed
--------
Tcl8.4 segfaults when calling Tcl_FindCommand() from a stubs enabled shared object.

The segfault occurs at the assembler instruction "call", and the program never makes it into the function. At the moment of the call instruction, the cpu register that holds the memory location to which the call is made, holds the value 0x0.

Running the code from the same shared lib in tclsh8.5 (8.5.7) does not exhibit the problem.

System specification:

% parray tcl_platform
tcl_platform(byteOrder) = littleEndian
tcl_platform(machine)   = i686
tcl_platform(os)        = Linux
tcl_platform(osVersion) = 2.6.18.8-0.13-default
tcl_platform(platform)  = unix
tcl_platform(user)      = erik
tcl_platform(wordSize)  = 4
% set tcl_patchLevel
8.4.19


How to reproduce
----------------
Attached to this report is the code for a Tcl extension that registers a new command "findcommand" in file fc.c. Also attached is the build script to produce the shared lib "fc.so". Assuming the completion of the build, you simply do:

> tclsh8.4
% load ./fc.so
% findcommand whatever
Segmentation fault (core dumped)


Preliminary analysis
--------------------

A. ddd inspection
Attached you find a screendump from the ddd debugger, showing:
- a breakpoint at the line in the C code where the call to Tcl_FindCommand is made
- the assembler instructions from that breakpoint up to the call instruction which fails.
- the cpu registers just before the call instruction.
Note the 0x0 value in the edx register.

B. backtrace from core dump: see attached file gdb_backtrace.txt


Preliminary interpretation
--------------------------
Since Tcl itself has calls to Tcl_FindCommand all over the place without them giving cause to complain, there must be something out of the ordinary. Maybe an issue with the stubs interface?

allow_comments - 1


One way to help catch such things is to use

    Tcl_InitStubs(interp, TCL_VERSION, 0);

so that your extension will demand at the
time it is [load]ed to have a Tcl interp at least
as new as the headers it was compiled against.
When that fails, a [load] error is more useful
than a crash.

You are right.
The header file was picked up from the system-installed include directory, which held header files of tcl8.5 .

Invalid issue indeed.

Sorry for the noise.

I suspect you compiled your code against Tcl 8.5
(or later) header files, then tried to [load] into a
Tcl 8.4 interp.  That does not work.

Compile against the header files of the earliest
version you wish to support [load]ing into.

File Added - 343246: tclsh8.4g.png

File Added - 343245: gdb_backtrace.txt

File Added - 343244: build

File Added - 343243: fc.c