Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-3084489 ] Serious issue: Tcl_DuplicateObj isn't making a copy?
|
From: SourceForge.net <no...@so...> - 2010-10-10 15:50:11
|
Bugs item #3084489, was opened at 2010-10-10 02:43 Message generated for change (Comment added) made by ferrieux You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3084489&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: 10. Objects Group: obsolete: 8.5.7 Status: Pending Resolution: Invalid Priority: 5 Private: No Submitted By: Alex Hisen () Assigned to: miguel sofer (msofer) Summary: Serious issue: Tcl_DuplicateObj isn't making a copy? Initial Comment: http://mkextensions.sourceforge.net/mkGeneric13.htm package provides C commands called lminus and linter. Under Tcl 8.4 the commands work as expected. Under Tcl 8.5.7 (running in AOLserver 4.5 on Windows, have not tested on any other platform), providing a pure tcl list (no string rep) as an argument to lminus will result in having the original list's list structure resorted. (In the scenario in which I discovered this, I actually see the string rep retain the original sequence even as list commands return data in different sequence from its string rep but I don't have a simple test case for that side-effect). As far as I can tell by looking at the source for this command, the first thing it does is Tcl_DuplicateObj (arvg[1]) (it uses a _DOB macro) and then performs its sort operation on the resulting object. Here is Tcl code you can use to replicate this problem: set listA [list c b a] set listB [list c b a z] lminus $listB $listA lindex $listA 0 - will return a instead of c Again lists must be pure. If you do set listA "c b a", the problem does not occur. Feel free to email to al...@am... with any questions ---------------------------------------------------------------------- >Comment By: Alexandre Ferrieux (ferrieux) Date: 2010-10-10 17:50 Message: Oh you're right Miguel ! I was saying this from the core's POV, not the extension... Certainly didn't want to dent the OP's motivation to file a bug report to mk :) ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2010-10-10 15:31 Message: Internal workings of internal reps is ... indeed internal, not part of the api :P You should not write to the intReps of any obj, except through the api. Or be prepared to update your code if/when internal workings change. As to the "nasty things": this is done to avoid having to copy things over when you just want to get a list obj that is protected against shimmering, and do it cheaply (without copying). ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2010-10-10 15:10 Message: Indeed that's an mk bug, but we have to admit that the Tcl core does nasty tricks with lists. Indeed, the List internal repr has its own level of refcounting, and the dupProc of the List type uses this to do as little work as reasonable: it only shares the internal rep, upping the refcount ! A secondary consequence is that (!Tcl_IsShared) does not allow to modify in place; the deeper test on listRepPtr->refCount is needed... As a result, all functions that do copy-on-write on lists *must* use more explicit duplication at the deeper level of intreps, eg by calling NewListIntRep. None of this is discussed in ListObj." by the way :( ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2010-10-10 13:18 Message: This is almost certainly a bug in mk stuff, not Tcl. Please report to that project, or provide evidence that it is a Tcl problem. I could not easily find the source for lminus, so can't tell for sure. But here's my guess: there is a call of TclListObjGetElements, and then a sort is done in place. This is NOT a valid usage. To quote the manual http://www.tcl.tk/man/tcl8.5/TclLib/ListObj.htm: "The memory pointed to is managed by Tcl and should not be freed or written to by the caller." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3084489&group_id=10894 |