Tcl Source Code

View Ticket
Login
Ticket UUID: 1326087
Title: Crash: UpdateStringProc should not be invoked for type cmdNa
Type: Bug Version: obsolete: 8.4.2
Submitter: israelt Created on: 2005-10-13 18:41:08
Subsystem: 10. Objects Assigned To: msofer
Priority: 5 Medium Severity:
Status: Closed Last Modified: 2005-12-23 04:37:41
Resolution: Invalid Closed By: msofer
    Closed on: 2005-12-22 21:37:41
Description:
OS is Linux 9. We are using Tcl objects functionality in 
our application.

If you type:

[lindex [get_cells] 1] you will get the message plus 
crash:

UpdateStringProc should not be invoked for type 
cmdName

get_cells is a command that return a list of Tcl objects.

Thanks,

Israel
User Comments: msofer added on 2005-12-23 04:37:41:
Logged In: YES 
user_id=148712

Tcl will manage the obj's string rep; just make sure that it
is alloced by us (Tcl_Alloc, or else Tcl_NewStringObj, or
Tcl_SetStringObj, ...). And freeIntRepProc should definitely
leave the string rep alone!

Closing this ticket as "Invalid" - if the docs at
http://tcl.tk/man/tcl8.4/TclLib/ObjectType.htm can be
improved, please open a new bug report with your suggestion.

israelt added on 2005-12-23 04:28:50:
Logged In: YES 
user_id=377302

Thanks for the info. The current implementation of the Tcl 
cell object freeIntRepProc does clear and free the object 
string rep. When I comment out this the crash does not 
happen. So I guess the Tcl library is going to clear and 
free this for me. Is this correct? The Tcl API 
documentation does not give specific information about 
this.

msofer added on 2005-12-23 02:55:03:
Logged In: YES 
user_id=148712

Not much more info; this means that it may not have been
refCount mishandling. To make sure, please try again using
--enable-symbols=mem (and no -DPURIFY) - although I do not
expect real news there.

We will definitely need more info on [get_cells] - in
particular, on its element #1. What type does it have? Are
we sure that that type is properly coded? In particular,
that its freeIntRepProc does not modify/clear the obj's
string rep?

israelt added on 2005-12-22 01:10:44:

File Added - 160717: stack_trace.txt

israelt added on 2005-12-22 01:10:43:
Logged In: YES 
user_id=377302

I compiled with the -DPURIFY but didn't see any messages 
from Tcl. I attached is the stack trace.

israelt added on 2005-12-22 01:03:39:

File Added - 160715: stack_trace.txt

israelt added on 2005-12-22 01:03:37:
Logged In: YES 
user_id=377302

I compiled with the -DPURIFY but didn't see any messages 
from Tcl. I attached is the stack trace.

sf-robot added on 2005-10-29 09:20:15:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

msofer added on 2005-10-15 04:31:14:
Logged In: YES 
user_id=148712

Mmhhh ... that stack trace is not very useful. The one thing
that one can tell from it is: Tcl is trying to interpret as
a command name some Tcl_Obj that has a NULL string rep and a
tclCmdNameType internal rep. Under those conditions, the
panic is inevitable. We have to find out how the heck this
situation came to be.

From what you say in the original report: the culprit is
whatever you stuck as element #1 in [get_cells]. 

Please compile with symbols and -DPURIFY - you will need to
compile your extension with -DPURIFY too. The -DPURIFY will
help us detect early if there is a problem with your
refCount handling. As it is, I suspect that you are unduly
freeing the element #1 of [get_cells]. 

Please provide enough evidence that this is a Tcl bug, or
enough data so that we can determine if it is. If you really
need to hide the stack trace into your extension and the
extension source code, you may need to hire a consultant to
help you debug this.

israelt added on 2005-10-15 04:08:43:

File Added - 152600: stack_trace.txt

Logged In: YES 
user_id=377302

The issue is happenning also in 8.4.11. The use count is 
correct, I checked this more than once.

Attached is the stack trace.

msofer added on 2005-10-14 03:45:46:
Logged In: YES 
user_id=148712

Could you please confirm that it still happens in 8.4.11? No
use hunting for a bug that might already be fixed.

This looks very much like Tcl_Obj mismanagement. First step
is to make sure that your Tcl_IncrRefCount() and
Tcl_DecrRefCount() are in order.

A stack trace might help you, but only if you compile with
-DPURIFY. This is likely to change the mode of failure,
giving us a better idea of what/when is failing. [NOTE:
please attach the stack trace, do not inline it in your comment]

In order to do that, configure with --enable-symbols, then
edit the Makefile to have 
CFLAGS_DEBUG = -g -DPURIFY

israelt added on 2005-10-14 03:24:20:
Logged In: YES 
user_id=377302

Hi miguel,

Our C++ application is linked to the Tcl library, we are 
creating commands and Tcl objects. get_cells is one of our 
command. We have hundrends of commands and tens of Tcl 
objects of different types.

Our Tcl objects do have string representation, the function 
implemeted for our Tcl object to update the string value is 
working correctly, if you do just "lindex [get_cells] 1" it works 
just fine (i.e. return the first cell object and the cell name is 
displayed) but if you put [] around this statement it will crash.

Let me know if you would like me to run this inside the 
debugger and send you the stack trace.

Thanks,

Israel

hobbs added on 2005-10-14 03:11:34:
Logged In: YES 
user_id=72656

Does this happen in 8.4.11?  What object system are you
using?  Are other C extensions involved?

msofer added on 2005-10-14 01:53:32:
Logged In: YES 
user_id=148712

Is your app pure tcl, or does it include c-coded extensions?
In particular get_cells. 

This crash (actually, a panic) hints at defective Tcl_Obj
handling - possibly in the core, more likely in an extension
if you're using one. It indicates that Tcl_GetString() or
Tcl_GetStringFromObj() has been called on a cmdNameType
Tcl_Obj that has no string representation, a state that
should never occur.

Attachments: