Tcl Source Code

View Ticket
Login
Ticket UUID: 2910748
Title: direct eval on BC spoilage is not NRE-aware
Type: Bug Version: obsolete: 8.6b1.1
Submitter: msofer Created on: 2009-12-08 15:17:43
Subsystem: 60. NRE and coroutines Assigned To: dgp
Priority: 9 Immediate Severity:
Status: Closed Last Modified: 2010-01-22 00:24:11
Resolution: Fixed Closed By: msofer
    Closed on: 2010-01-21 17:24:11
Description:
See http://groups.google.co.uk/group/comp.lang.tcl/browse_frm/thread/521f924c167872a6
User Comments: msofer added on 2010-01-22 00:24:11:

allow_comments - 1

dgp added on 2010-01-21 23:52:37:

File Added - 359760: 2910748-2.patch

dgp added on 2010-01-21 23:50:06:
Attached amended patch solves the failing test.

Note that the issue here is just a repeat of the same
issue in Bug 2037338.

dgp added on 2010-01-21 11:57:00:
The execute-8.4 failure is due to the following,
which for the moment I'm thinking is a flaw in
the INST_EVAL_STK instruction:

% proc foo0 {} {
  catch {error bar} m o
  return -options $o $m
}
% proc foo1 {} {
  catch {error bar} m o
  if 1 {return -options $o $m}
}
% proc foo2 {} {
  catch {error bar} m o
  set x 1
  if $x {return -options $o $m}
}
% foo0
bar
% set errorInfo
bar
    while executing
"error bar"
    (procedure "foo0" line 2)
    invoked from within
"foo0"
% foo1
bar
% set errorInfo
bar
    while executing
"error bar"
    (procedure "foo1" line 2)
    invoked from within
"foo1"
% foo2
bar
% set errorInfo
bar
    while executing
"error bar"
    invoked from within
"if $x {return -options $o $m}"
    (procedure "foo2" line 4)
    invoked from within
"foo2"

msofer added on 2010-01-19 22:34:23:
fixed bug# refs in patch

msofer added on 2010-01-19 22:34:05:

File Deleted - 359257: 



File Added - 359526: 2910748.diff

msofer added on 2010-01-17 20:41:48:
The attached patch fixes this issue, BUT it breaks execute-8.4: it was not committed

The new failure may be deemed to be a lesser bug (not prio 9); requesting review by dgp

msofer added on 2010-01-17 20:39:19:

File Added - 359257: 2037338.diff

msofer added on 2009-12-11 07:45:38:
On today's HEAD (after some rewrite of coro code) dkf's snippet does not crash, it causes an error instead: 'cannot yield: C stack busy'

dkf added on 2009-12-08 22:50:50:
Relatedly, the next snippet crashes (tested in a fresh debug build)

proc foo args {};foo;coro bar apply {{} {proc foo args {return ok}; foo; while 1 {yield [incr i];foo}}}

(Apparently, "nasty thing, causes a recompile ... yield in one bytecode, resume in another")

msofer added on 2009-12-08 22:30:31:
[12:27]dkfI think you'd get the same effect (spoilage of bytecode) by creating a command [proc assert args {}] which you use and then redefining that part way through
[12:28]dkfI suspect that it is bytecode spoilage that's key, not [namespace path] which is adding nothing that is bytecoded

Attachments: