[Tcl-bugs] [ tktoolkit-Bugs-2492179 ] config.test failures - DoObjConfig

[SourceForge.net <no...@so...>]

Bugs item #2492179, was opened at 2009-01-07 06:46
Message generated for change (Settings changed) made by jenglish
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=2492179&group_id=12997

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 23. Option Parsing
Group: current: 8.6b1
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Don Porter (dgp)
>Assigned to: Joe English (jenglish)
Summary: config.test failures - DoObjConfig

Initial Comment:

Don't recall seeing these before:

config.test


==== config-4.111 DoObjConfig - custom FAILED
==== Contents of test case:

    testobjconfig alltypes .foo -custom test

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0
---- errorInfo: unknown color name "test"
    (processing "-custom" option)
    invoked from within
"testobjconfig alltypes .foo -custom test"
    ("uplevel" body line 2)
    invoked from within
"uplevel 1 $script"
---- errorCode: NONE
==== config-4.111 FAILED



==== config-4.112 DoObjConfig - custom FAILED
==== Contents of test case:

    testobjconfig alltypes .foo -custom test
    .foo cget -custom

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0
---- errorInfo: unknown color name "test"
    (processing "-custom" option)
    invoked from within
"testobjconfig alltypes .foo -custom test"
    ("uplevel" body line 2)
    invoked from within
"uplevel 1 $script"
---- errorCode: NONE
==== config-4.112 FAILED



==== config-7.13 Tk_SetOptions - error in DoObjConfig with custom option FAILED
==== Contents of test case:

    .a configure -custom bad

---- Result was:
unknown color name "bad"
---- Result should have been (exact matching):
expected good value, got "BAD"
==== config-7.13 FAILED



==== config-7.14 Tk_SetOptions - error in DoObjConfig with custom option FAILED
==== Contents of test case:

    catch {.a configure -custom bad}
    return $errorInfo

---- Result was:
unknown color name "bad"
    (processing "-custom" option)
    invoked from within
".a configure -custom bad"
---- Result should have been (exact matching):
expected good value, got "BAD"
    (processing "-custom" option)
    invoked from within
".a configure -custom bad"
==== config-7.14 FAILED


----------------------------------------------------------------------

Comment By: Joe English (jenglish)
Date: 2009-01-10 17:21

Message:
I have a fix, but will hold off committing until #2496162 is resolved -- I
suspect the two bugs are related (something screwy going on in Tk option
processing, possibly being tickled by recent NRE-enabling of [source]), and
this one is a lot easier to replicate than that one.


----------------------------------------------------------------------

Comment By: Joe English (jenglish)
Date: 2009-01-10 16:47

Message:
Probable cause of the problem:

generic/tkTest.c r1.41, routine CustomOptionSet, lines 2138-2139 directly
modifies the string rep of a Tcl_Obj * without first ensuring that it's
unshared:

|        string = Tcl_GetStringFromObj((*value), &length);
|        Tcl_UtfToUpper(string);

Additional debug printfs() indicate that when running config.test, this
code path is indeed taken when (*value) has a refcount > 1.  

----------------------------------------------------------------------

Comment By: Joe English (jenglish)
Date: 2009-01-10 15:55

Message:
More info: tried several versions of Tk (using `git bisect`) against Tcl
CVS HEAD (as of 9 Jan 2009); getting sporadic, nondeterministic failures
for tests in the range config-4.108 through config-4.115, and
config-7.13/7.14 for all versions of Tk going back to tag core-8.6a1.  
Tried various combinations of valgrind, -DPURIFY, --enable-symbols=mem;
none of them bark, but I occasionally get a coredump.  Again,
nondeterministally and sporadically -- can't reliably replicate -- but the
coredump usually (always?) occurs somewhere in tkConfig.c.

Consistent pattern in the test failures: setting the "-custom" option of a
Test widget created by [testobjconfig] signals an error "bad <color
name|window path name| other thing> XXX", where "XXX" is usually (but not
always? Don't remember now and can't replicate, sigh...) the value
specified for "-custom".

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2009-01-09 11:57

Message:

I get similar failures using
the actual release sources of Tk 8.6b1
when built against the Tcl HEAD.

I do not get the failures
building against the Tcl 8.6b1
sources as released.

The bug may well still be in Tk.
But the triggering cause seems
to be some post-8.6b1 commit to Tcl.

Leading suspect is NRE-enabling
of [source].

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=2492179&group_id=12997