| Ticket UUID: | 2933089 | |||
| Title: | info frame incorrect source type results | |||
| Type: | Bug | Version: | obsolete: 8.5.8 | |
| Submitter: | cosmoweezer | Created on: | 2010-01-15 21:02:51 | |
| Subsystem: | 17. Commands I-L | Assigned To: | andreas_kupries | |
| Priority: | 5 Medium | Severity: | ||
| Status: | Closed | Last Modified: | 2010-02-03 03:52:17 | |
| Resolution: | Fixed | Closed By: | andreas_kupries | |
| Closed on: | 2010-02-02 20:52:17 | |||
| Description: |
The info frame sub-command gives incorrect results for source type line info under some conditions as illustrated by the attached sample file. This was tested against 8.5.6 and 8.5.8 on Windows. Prior versions such as 8.4.16 with TIP 280 and 8.5.1 provided correct results. | |||
| User Comments: |
andreas_kupries added on 2010-02-03 03:52:17:
allow_comments - 1 andreas_kupries added on 2010-02-03 03:52:16: Committed to CVS head of 8.5 branch. andreas_kupries added on 2010-02-03 03:51:29: The fix I had done in 8.6 backported cleanly and without change. andreas_kupries added on 2010-01-21 06:58:25: At first glance I thought that it is calling of get_info_frame through an execution trace which is the problem ... Doesn't seem to be the case however. A comparison of 8.4.19, 8.5.8, and 8.6 CVS head further shows that 8.6 is OK. It shows the correct line number for the uh-oh case, i.e. 35 ... And that brought me on the right track. The 'else' branches of all the if conditions are identical, character for character. I.e. they are the same literal, and the byte code compiler maps them to a single Tcl_Obj value in the generated bytecode. Why is that important ? Because some of the #280 info is tacked on the Tcl_Obj, and the older versions of the core then get confused. When I fixed the tracking of continuation lines in the CVS head (8.6+) I also did some literal-sharing work ... TclCompileObj, in tclExecute.c ... Hm. I thought there (per my comments) that 8.5 would not need such a fix. It seems I am mistaken. I will have a look, see if my 8.6 work i nthat area can be back-ported easily. A workaround for you is to change one of the else branches, for example by adding a space somewhere ... Then the strings are not identical and are not mapped to a single Tcl_Obj, and the line-counting logic gets it right. Side note: $$y ? That is very brittle Tcl, not idiomatic. See http://wiki.tcl.tk/8662 for a discussion of the subject. cosmoweezer added on 2010-01-16 04:02:52: File Added - 359106: info_frame.tcl | |||
Attachments:
- info_frame.tcl [download] added by cosmoweezer on 2010-01-16 04:02:51. [details]