Tcl Source Code

View Ticket
Bounty program for improvements to Tcl and certain Tcl packages.
18:48 Closed ticket [3592747fff]: (tailcall|yieldto) failed to find the proper namespace Abort plus 6 other changes artifact: f6eb7e98ae user: dgp
15:48 Ticket [3592747fff]: 3 changes artifact: 9d6a271afb user: dgp
07:24 Ticket [3592747fff]: 4 changes artifact: 3b249618d7 user: pooryorick
Fix for [3592747]: Let TclNRTailcallEval handle namespace problems. check-in: 9198c16407 user: pooryorick tags: core-8-6-branch
21:28 Ticket [3592747fff] (tailcall|yieldto) failed to find the proper namespace Abort status still Open with 3 other changes artifact: 550dd9940e user: pooryorick
17:12 Ticket [3592747fff]: 3 changes artifact: fb4a33dde0 user: pooryorick
17:00 Ticket [3592747fff]: 7 changes artifact: 8efa4ae70f user: pooryorick
16:27 Ticket [3592747fff]: 4 changes artifact: 8e6edf75e1 user: dkf
21:02 Ticket [3592747fff]: 5 changes artifact: c66f909656 user: msofer
09:39 Ticket [3592747fff]: 5 changes artifact: 25566c21c4 user: msofer
17:45 Ticket [3592747fff]: 4 changes artifact: dba2a226ba user: msofer
17:36 Ticket [3592747fff]: 5 changes artifact: 216959f721 user: msofer
15:41 Ticket [3592747fff]: 1 change artifact: 5a5aacc09f user: coldstore
08:40 New ticket [3592747fff]. artifact: f01b04dae5 user: coldstore

Ticket UUID: 3592747
Title: (tailcall|yieldto) failed to find the proper namespace Abort
Type: Bug Version: None
Submitter: coldstore Created on: 2012-12-05 08:40:10
Subsystem: 60. NRE and coroutines Assigned To: pooryorick
Priority: 8 Severity: Minor
Status: Closed Last Modified: 2018-06-28 18:48:32
Resolution: Fixed Closed By: dgp
    Closed on: 2018-06-28 18:48:32
Under some circumstances a coroutine can be invoked via ::yieldto while the namespace in which it resides is dying (nsPtr->flags&NS_DYING)

This may occur, and is occuring, for example, when a TclOO object is being destroyed, and a coroutine within it is invoked by an event.

The call to TclGetNamespaceFromObj() at tclBasic.c:8532 will indicate an error, because the current frame's namespace is not considered to match itself in the case that it is dying.

I am unsure what the purpose of the test is, or under what circumstances the two namespaces might differ, but this abort occurs as a result of script evaluation, and hence should be considered a bug.
User Comments: dgp added on 2018-06-27 15:48:31:
This is now fixed and the ticket can be closed?

pooryorick added on 2018-06-24 07:24:20:

In [9198c16407f3] namespace handling is removed from TclNRTailcallObjCmd, allowing TclNRTailcallObjCmd to handle namespace issues later. This aligns the behaviour of the non-compiled variant with the compiled one: An error is produced if the namespace is not found.

pooryorick added on 2018-06-23 21:28:39:

If {*} from the example the compiled path for tailcall is taken, and in the compiled variant an error is raised:

namespace "::ns" not found

pooryorick added on 2018-06-23 17:12:25:

A slightly smaller example:

namespace eval ns {
	proc p args {
		::tailcall [namespace current] {*}$args
	namespace delete [namespace current]

pooryorick added on 2018-06-23 17:00:22:

The following script reproduces the issue:

namespace eval ns {
    proc p args {
        ::tailcall [namespace current] {*}$args
    namespace eval [namespace current] {
        namespace delete [namespace current]

TIP 498 is one solution to this issue.

dkf added on 2013-03-20 16:27:56:
This is why it's great to have a test, so we can confirm when the bug is dead…

msofer added on 2013-03-19 21:02:55:
Is this bug still present?

msofer added on 2012-12-06 09:39:05:
The problem is indeed with [tailcall] whose guts are reused by [yieldto]. The current namespace was being cached in an nsNameType Tcl_Obj in order to insure its survival, and as a failure to resolve "could not happen" it was signaled by a panic. As colin is wont to do, he triggered the impossible! Fixed by using a better lifetime management of the namespace.

msofer added on 2012-12-05 17:45:00:
Note: the problem is likely to appear also with [tailcall].

msofer added on 2012-12-05 17:36:45:
1. no script to repro?
2. any suggestion as to what should happen in that case? Would an error be in order?