Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#1555 [gets] corrupts freed object

obsolete: 8.3.1
closed-fixed
5
2001-08-06
2001-07-19
Jonathan Kamens
No

The function Tcl_GetsObjCmd in tclIOCmd.c can corrupt a
freed object if it is called with objc == 3. This is
because it retrieves resultPtr and does not increment
its reference count, but then calls Tcl_ObjSetVar2,
which causes the retrieved resultPtr object to be
released. I will attach a patch, which I hope is
correct (if not, please E-mail me and let me know why,
so I can understand all of this better; I barely
understand it).

Discussion

  • Patch to avoid corrupting released object

     
    Attachments
  • Don Porter
    Don Porter
    2001-07-19

    • labels: 105657 --> 24. Channel Commands
    • summary: gets corrupts freed object --> [gets] corrupts freed object
     
  • Logged In: YES
    user_id=75003

    Regarding "Tcl_ObjSetVar2" releasing the interp result. I
    took a look at the principal code, in "Tcl_SetVar2Ex" and
    found that the interp result is only released in the case
    of an error. In that case the result of the function is
    NULL, and this condition is catched by "Tcl_GetsObjCmd". So
    this shouldn't be a problem.

     
  • Logged In: YES
    user_id=75003

    Still, in the code as is the call to "Tcl_GetsObj" can and
    will directly modify the interp result without announcing
    its reference in the case of objc == 2. This gave trouble
    in the past with transformations, i.e. channel drivers,
    which called back into the script level, thus modifying the
    interp result, if they didn't do a save/restore on the
    previous result.

     
    • assigned_to: nobody --> andreas_kupries
     
  • Logged In: YES
    user_id=274776

    Hmm. I'm not following everything that Andreas is saying.
    I confess that I didn't fully understand the mechanisms I
    was trying to fix. But I assure you that TCL was
    core-dumping without my fix, and when I recompiled it with
    TCL_MEM_DEBUG, the call to Tcl_SetIntObj was failing,
    claiming that it was trying to set a disposed pointer. When
    I recompiled with my fix, that error went away when
    TCL_MEM_DEBUG remained set and the coredump went away when I
    unset it.

    I don't think I have anything more useful to contribute :-).

     
  • Logged In: YES
    user_id=75003

    Can you attach the script which produces the core dump to
    this item ?

     
  • Logged In: YES
    user_id=274776

    No, I can't, because it's a large package (cbb, the Check
    Book Balancer) with lots of local customizations, and the
    coredump seems to be dependent on the specific data being
    imported, and I can't exactly send you my checkbook data.

    I had sort of hoped that the correctness of my fix would be
    apparent to someone who understands tcl's internals more
    than I do. It was *mostly* apparent to me, and I barely
    understand the internals at all. Apparently it's more
    complex than I thought.

     
  • Logged In: YES
    user_id=75003

    Comitted.

     
    • status: open --> closed-fixed
     
  • Logged In: YES
    user_id=274776

    I'm finding this whole conversation really puzzling. I'm
    sorry to keep repeating myself, but I find it necessary to
    do so....

    As I said, I can't comment on *why* there's a problem in the
    code. All I know is that when I compiled TCL with memory
    debugging enabled, the memory debugging code told me quite
    explicitly that there was a problem, and after I applied the
    fix which I submitted, the problem went away.

    What I find puzzling is that you seem willing to write off
    this bug and close it without determining why I was seeing a
    problem before my fix and not afterwards. It seems like you
    think I'm making up the bug report or something. Why would
    I make up the fact that the TCL memory debugging code was
    reporting a problem before my fix and not reporting a
    problem afterwards?

    In short, it seems to me that you should not close the bug
    without taking any action until you have understood why I
    was seeing a problem, and it seems that you haven't done
    that.

     
  • Don Porter
    Don Porter
    2001-08-07

    Logged In: YES
    user_id=80530

    Why are you complaining? Your patch was accepted into
    the development sources and will be part of releases
    Tcl 8.3.4 and Tcl 8.4a3. Isn't that what you want?

     
  • Logged In: YES
    user_id=274776

    Doh! I was complaining because I thought my patch *wasn't*
    accepted! I misread the bug report because I read it from
    top to bottom when I should have been reading it from bottom
    to top. I find this interface which puts the description of
    the bug first but then puts comments from most to least
    recent quite confusing :-).

    Sorry about that. Thanks.