Menu ▾ ▴

#3087 place-14.1 fail - MEMLEAK!

current: 8.5.14
open
Peter Spjuth
51. [place] (10)
5
2013-04-01
2013-04-01
Don Porter
No

Testing a --enable-symbols=all build of Tk 8.5.14
revealed that place-14.1 fails:

==== place-14.1 memory leak testing FAILED
==== Contents of test case:

# Test all manners of forgetting a slave
frame .f
frame .f.f
stress {
place .f.f -x [expr {1 + 1}] -y [expr {2 + 2}]
place forget .f.f
} {
place .f.f -x [expr {1 + 1}] -y [expr {2 + 2}]
pack .f.f
} {
place .f.f -x [expr {1 + 1}] -y [expr {2 + 2}]
destroy .f
frame .f
frame .f.f
}

---- Result was:
0 0 104
---- Result should have been (exact matching):
0 0 0
==== place-14.1 FAILED

This failure indicates a memory leak.

Further testing revealed that 8.5.13 has the same
leak. Since this is not a regression, it will not
block 8.5.14 release, but it's still a serious bug
we should hunt down and kill.

Discussion

  • Don Porter

    Don Porter - 2013-04-01

    This bug is devilish because it's not reliably
    reproducible, so you can convince yourself it's
    not there. Makes bisecting near futile.

    I've observed the test failure (not reliably, mind you,
    but as an existence proof) in the 8.5.2 releases of
    Tcl/Tk -- the root of the core-8-5-branch.

    Dropping to normal priority. This could be a giant
    of a goose chase.

     

  • Don Porter

    Don Porter - 2013-04-01
    • priority: 8 --> 5
     

  • Don Porter

    Don Porter - 2013-04-02

    The test itself may not be reliable.
    I am able to make it report a "leak"
    of -104 (notice the minus sign).

     

  • Don Porter

    Don Porter - 2013-04-02

    The test arrived in checkin

    core.tcl.tk/tk/ci/419a463e2341fcdc

    and I can observe it failing in that state of the code.

    However, the demo script of bug 1028888 does not
    show memory growth. That leak was successfully
    fixed.

    When I see the test fail, I need other tests to run
    in addition to this one. Often the options

    make test TESTFLAGS="-file [m-p]\*.test"

    are enough.

    Less reliably, it seems that the failure is more
    likely to happen when the display is used
    (mouse moved; window focus changed) while
    the test suite runs. I never test on an unused
    display, so I cannot make that distinction with
    certainty.

    My sense is that the symptom is mostly a weakness
    of this particular test, picking up either the appearance
    of a leak that isn't there, or picking up the evidence of
    a leak that is lurking in there somewhere, but isn't the
    fixed one the test was designed to prove the fix for.