Tcl Source Code

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

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.

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

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.

Logged In: YES 
user_id=75003

Comitted.

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

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

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

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.

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.

File Added - 8593: diff