Tcl Source Code

Recently started seeing these
failures on the ../macosx build.

They don't appear to be reliable,
failing only some of the time.
The ../unix build on Mac OS X
doesn't show these failures.

==== iocmd.tf-22.9 chan finalize, for close, ignore
level, close error FAILED
==== Contents of test case:

    set res {}
    proc foo {args} {track; oninit; return -level 5
-code 777 BANG}
    note [set c [chan create {r w} foo]]
    notes [inthread $c {
        note [catch {close $c} msg opt]; note $msg;
note $opt
        notes
    } c]
    rename foo {}
    set res

---- Result was:
{initialize rc117 {read write}} rc117 {finalize rc117}
1 BANG {-code 1 -level 0 -errorcode NONE -errorline 11
-errorinfo BANG}
---- Result should have been (glob matching):
{initialize rc* {read write}} rc* {finalize rc*} 1 BANG
{-code 1 -level 0 -errorcode NONE -errorline 1
-errorinfo BANG}
==== iocmd.tf-22.9 FAILED

==== iocmd.tf-25.10 chan configure, cgetall, level is
ignored FAILED
==== Contents of test case:

    set res {}
    proc foo {args} {
        oninit cget cgetall; onfinal; track
        return -level 55 -code 777 BANG
    }
    set c [chan create {r w} foo]
    notes [inthread $c {
        note [catch {fconfigure $c} msg opt]
        note $msg
        note $opt
        close $c
        notes
    } c]
    rename foo {}
    set res

---- Result was:
{cgetall rc148} 1 BANG {-code 1 -level 0 -errorcode
NONE -errorline 11 -errorinfo BANG}
---- Result should have been (glob matching):
{cgetall rc*} 1 BANG {-code 1 -level 0 -errorcode NONE
-errorline 1 -errorinfo BANG}
==== iocmd.tf-25.10 FAILED



Appears to just be a mismatch in
the -errorline value, which I really
don't understand.

File Added - 167824: 1372348.patch

Logged In: YES 
user_id=80530


committing attached patch.

Logged In: YES 
user_id=75003

[12:22]dgpaku?
[12:22]aku.
[12:22]dgpI see you're back in the chat.
[12:23]dgpdoes that mean vacation is over?
[12:23]akuyes
[12:23]dgpwhen you have a chance, let me know what you
think of 1372348

[12:24]akuOh, the reflection test failures ...
[12:25]akuWill have to read all the comments before saying
anything ...
[12:25]dgpdiagnosis is complete, just need you to make a
design choice about the proper fix.
[12:28]akuIMHO we should keep the conversion TCL_RETURN ->
TCL_ERROR.  From the TIP ...

[12:28]akuAs a safety precaution any -level specification
submitted by the driver and a non-zero value will be
rewritten to a value of 0 to prevent the driver from being
able to force the user application into the execution of
arbitrary multi-level returns, i.e. from arbitrarily
changing the control-flow of the application itself.
Analogously any -code specification with a non-zero value
which is not error is rewritten to value 1 (i.e. error).

[12:29]akuI.e. I am doing this to prevent a possibly
security hole, stop people from playing hooky from the start.

[12:29]dgpok, if you want to copy that comment to the
report and assign back to me, that would be fine.
[12:29]akuCan do.
[12:29]akuI am not sure how to get all the errorInfo data
you are asking for.

Logged In: YES 
user_id=80530


the proper fix involves
a choice.

either TCL_RETURN can
be marshalled and returned
along with the correct
values of -level and -code

or, if the proper thing
really is conversion of
all non-TCL_OK codes to
TCL_ERROR, then at the
time of that conversion,
values for -errorinfo
-errorcode and -errorline
should be provided, as
they are for the creation
of any TCL_ERROR.

Logged In: YES 
user_id=80530


the problem is in
the shift of the return
code from TCL_RETURN
to TCL_ERROR.

Although the script evaluation
returned TCL_RETURN, the code
TCL_ERROR is being passed to
Tcl_GetReturnOptions() in
MarshallError().

T_GRO expects to receive the
return code that the script
evaluation returned, IIRC.

continuing...

Logged In: YES 
user_id=80530


ok, common to all the
failing tests are -level
values that are bigger
than the stack depth at
which the code runs.

this means TCL_RETURN
is the return code from
Tcl_EvalObjv() at line
2012 of tclIORChan.c
indicating this is
likely an error in
the MarshallError() routine.

continuing...

Logged In: YES 
user_id=80530


BTW, it's a complete mystery
to me what the strange custom
-code values coupled with large
-level values are meant to accomplish.

These appear to be present in
all the tests I've seen fail or
seen reported to fail.  (1356071)

Either simplify or comment with
explanations.

Logged In: YES 
user_id=80530


looking more carefully,
it doesn't appear that
the transfer of return
options through a thread
interface is involved
in the test failures.

Instead have to look more
carefully at how the results
of the script level channel
callbacks get treated in the
channel reflection code.

Logged In: YES 
user_id=80530


just a guess... is this
indicating a failure of
some [thread eval] mechanism
to pass through the complete
return options dictionary?
Something in the [testthread]
command that hasn't been updated
to handle the TIP 90 stuff?

Logged In: YES 
user_id=90580

indeed these tests only run when configured with --enable-threads, since 
they have a testthread constraint...

BTW, just saw these failures again, on the SF compilefarm host x86-linux2
Also saw equivalent failures of iocmd.tf-24.13 and iocmd.tf-26.7 when 
running with TESTFLAGS='-file ioCmd.test'

in all cases '-errorline 11' instead of the expected '-errorline 1' causes the 
failure.

Logged In: YES 
user_id=80530


Is --enable-threads the common
denominator then?

Logged In: YES 
user_id=90580

I have seen this failure, but also on platforms other than Mac OS X, so I don't 
think it is platform specific.

Logged In: YES 
user_id=79902

Looks very much like a dup of 1356071, though that's with a
different test from the same group (iocmd.tf-27.6).

Something deeply screwy is going on.