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 |