Starting at the following build, test_idle started to leak references:
http://buildbot.python.org/all/builders/AMD64%20Windows8.1%20Refleaks%203.x/builds/60/steps/test/logs/stdio

Example of leak:

$ ./python -m test -R 3:3 -u all test_idle -m idlelib.idle_test.test_configdialog.FontPageTest.test_set_samples
(...)
test_idle leaked [2168, 2168, 2168] references, sum=6504
test_idle leaked [1152, 1154, 1155] memory blocks, sum=3461
(...)

A bisection identified this commit:

commit 9397e2a
Author: csabella <cheryl.sabella@gmail.com>
Date: Sun Jul 30 13:34:25 2017 -0400

bpo-31004: IDLE: Factor out FontPage class from configdialog (step 1) (bpo-2905)

The slightly modified tests continue to pass. The General test
broken by the switch to Notebook is fixed.
Patch mostly by Cheryl Sabella.

I don't know anything about idlelib, but it seems like the following patch fixes the failing test:

diff --git a/Lib/idlelib/idle_test/test_configdialog.py b/Lib/idlelib/idle_test/test_configdialog.py
index aff3c2f..9f495fd 100644
--- a/Lib/idlelib/idle_test/test_configdialog.py
+++ b/Lib/idlelib/idle_test/test_configdialog.py
@@ -41,6 +41,7 @@ def tearDownModule():
     global root, dialog
     idleConf.userCfg = usercfg
     tracers.detach()
+    tracers.clear()
     del dialog
     root.update_idletasks()
     root.destroy()

Extract of ConfigDialog.create_page_highlight():

        self.builtin_theme = tracers.add(
                StringVar(parent), self.var_changed_builtin_theme)

This method contains many tracers.add() calls, but tearDownModule() of Lib/idlelib/idle_test/test_configdialog.py only calls "tracers.detach()" and detatch() doesn't clear VarTrace.untraced list.

Attached is an improved idlelib.idle_test.test_* leak checker that uses the --match option.

New changeset 733d0f6 by Terry Jan Reedy in branch 'master':
bpo-31130: IDLE -- stop leaks in test_configdialog. (bpo-3016)
733d0f6

New changeset 9d7d928 by Terry Jan Reedy in branch '3.6':
[3.6] bpo-31130: IDLE -- stop leaks in test_configdialog. (GH-3016) (bpo-3018)
9d7d928

I confirm that test_idle doesn't leak anymore:

$ ./python -m test -R 3:3 -u all test_idle 
1 test OK.

The merged change is the correct fix. My change was only a workaround.

Thanks for the fix Terry ;-)

Victor: Something seems to have changed in the last few days. When I merged, both specific classes
python -m test -R 3:3 -u gui -v test_idle -m idlelib.idle_test.test_configdialog.FontPageTest.*
and the module as a whole passed.
python -m test -R 3:3 -u gui -v test_idle -m idlelib.idle_test.test_configdialog.*.*

Today, not having touched configdialog or test_configdialog, test_configdialog as a whole passes but FontPageTest, IndentTest, and GenPageTest fail with
test_idle leaked [1, 1, 1, 1] memory blocks, sum=4
(Tested individually, VarTraceTest and the empty HighlightTest pass.)
I presume that cleanUpModule still runs with the restriction.

Could any of your other recent changes to regrtest have introduced a spurious 1 block error when tests are filtered?

test_idle leaked [1, 1, 1, 1] memory blocks, sum=4

While reference leaks are more or less stable, the check on memory blocks is fragile.

I'm unable to reproduce your issue on Linux. I tested "./python -m test -R 3:3 -u gui -v test_idle". If you have a reproductible failure, please open a new issue since this one is closed.

If you consider that it's a recent regression, you can go back in history using git checkout <old sha1>, or even git bisect.

If you open a new issue, you may want to use "python -m test.bisect ..." to identify which test leaks memory blocks.

My message was most a heads-up. As I said, I only get the 1 block leak with a micro test of a class or method. It is possible that even that is Windows-specific. As long as you only care that test_idle not leak, I don't care about this either.

As I said, I only get the 1 block leak with a micro test of a class or method.

Yeah, again, the memory block check is fragile. It might be an legit internal cache filled for good reasons. It can be a free list. It can be a lot of things. It's really hard to track such very tiny memory allocation. "leaked [1, 1, 1, 1] memory blocks" can be a false alarm, it's not big.