#3267 Crash: UpdateStringProc should not be invoked for type cmdNa

obsolete: 8.4.2
closed-invalid
5
2005-12-22
2005-10-13
No

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

Discussion

  • miguel sofer

    miguel sofer - 2005-10-13

    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.

     
  • miguel sofer

    miguel sofer - 2005-10-13
    • assigned_to: hobbs --> msofer
    • labels: 105661 --> 10. Objects
     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2005-10-13

    Logged In: YES
    user_id=72656

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

     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2005-10-13
    • status: open --> pending-out-of-date
     
  • Israel Taller

    Israel Taller - 2005-10-13
    • status: pending-out-of-date --> open
     
  • Israel Taller

    Israel Taller - 2005-10-13

    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

     
  • miguel sofer

    miguel sofer - 2005-10-13

    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

     
  • Israel Taller

    Israel Taller - 2005-10-14

    Stack trace

     
  • Israel Taller

    Israel Taller - 2005-10-14

    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.

     
  • miguel sofer

    miguel sofer - 2005-10-14
    • status: open --> pending
     
  • miguel sofer

    miguel sofer - 2005-10-14
    • status: pending --> pending-invalid
     
  • miguel sofer

    miguel sofer - 2005-10-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.

     
  • SourceForge Robot

    • status: pending-invalid --> closed-invalid
     
  • SourceForge Robot

    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).

     
  • Israel Taller

    Israel Taller - 2005-12-21
    • status: closed-invalid --> open
     
  • Israel Taller

    Israel Taller - 2005-12-21

    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.

     
  • Israel Taller

    Israel Taller - 2005-12-21

    Stack trace

     
  • Israel Taller

    Israel Taller - 2005-12-21

    Stack trace

     
  • Israel Taller

    Israel Taller - 2005-12-21

    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.

     
  • miguel sofer

    miguel sofer - 2005-12-22

    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?

     
  • Israel Taller

    Israel Taller - 2005-12-22

    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.

     
  • miguel sofer

    miguel sofer - 2005-12-22

    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.

     
  • miguel sofer

    miguel sofer - 2005-12-22
    • status: open --> closed-invalid
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks