|Title:||(tailcall|yieldto) failed to find the proper namespace Abort|
|Submitter:||coldstore||Created on:||2012-12-05 08:40:10|
|Subsystem:||60. NRE and coroutines||Assigned To:||pooryorick|
|Status:||Closed||Last Modified:||2018-06-28 18:48:32|
|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.
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
pooryorick added on 2018-06-23 21:28:39:
pooryorick added on 2018-06-23 17:12:25:
A slightly smaller example:
pooryorick added on 2018-06-23 17:00:22:
The following script reproduces the issue:
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?