[Tcl-bugs] [ tcl-Bugs-2860233 ] Calling Tcl_FindCommand() from a shared lib segfaults

[SourceForge.net <no...@so...>]

Bugs item #2860233, was opened at 2009-09-16 15:41
Message generated for change (Comment added) made by dgp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2860233&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Erik Leunissen (eriklns)
>Assigned to: Don Porter (dgp)
Summary: Calling Tcl_FindCommand() from a shared lib segfaults

Initial Comment:
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?


----------------------------------------------------------------------

>Comment By: Don Porter (dgp)
Date: 2009-09-17 13:43

Message:

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.




----------------------------------------------------------------------

Comment By: Erik Leunissen (eriklns)
Date: 2009-09-17 13:22

Message:
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.


----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2009-09-16 18:27

Message:

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.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2860233&group_id=10894