Issue 36155: ./python -m test -m test_gc fails (original) (raw)

Created on 2019-03-01 07:29 by xtreak, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 12116 merged pablogsal,2019-03-01 08:53
Messages (12)
msg336898 - (view) Author: Karthikeyan Singaravelan (xtreak) * (Python committer) Date: 2019-03-01 07:29
I am not sure of the exact cause about this failure but `./python.exe -m test -m test_gc` fails though `./python.exe -m test -v test_gc` passes. This test was recently added with 175421b58cc97a2555e474f479f30a6c5d2250b0 and . ./python.exe -m test -m test_gc == CPython 3.8.0a2+ (heads/master:f684d83d86, Mar 1 2019, 10:39:16) [Clang 7.0.2 (clang-700.1.81)] == macOS-10.10.4-x86_64-i386-64bit little-endian == cwd: /Users/karthikeyansingaravelan/stuff/python/cpython/build/test_python_21045 == CPU count: 4 == encodings: locale=UTF-8, FS=utf-8 Run tests sequentially 0:00:00 load avg: 1.85 [ 1/420] test_grammar [snip] 0:00:36 load avg: 2.17 [156/420] test_gc -- test_future5 run no tests test test_gc failed -- Traceback (most recent call last): File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/test/test_gc.py", line 775, in test_get_objects self.assertNotIn(l, gc.get_objects(generation=2)) AssertionError: [[...]] unexpectedly found in <list object at 0x112b5d668> 0:00:48 load avg: 2.14 [157/420/1] test_gdb -- test_gc failed
msg336900 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2019-03-01 07:57
It seems that some collection from some other test is happening between the three calls to get_objects: self.assertIn(l, gc.get_objects(generation=0)) self.assertNotIn(l, gc.get_objects(generation=1)) self.assertNotIn(l, gc.get_objects(generation=2)) The easiest solution is deactivating the gc at the beginning of the test and reactivating it afterwards, as the test is relying on manual collection. In this way, external collections cannot affect the test. I will prepare a PR.
msg336901 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2019-03-01 08:14
This may be more complicated that it seems as these two statements are true at the same time: l in gc.get_objects(generation=0) True p l in gc.get_objects(generation=2) True
msg336902 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2019-03-01 08:15
But this only happens when running the test suite as ./python.exe -m test -m test_gc
msg336903 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2019-03-01 08:48
Ok, this is happening because there is a unittest.mock._ANY in the second generation.
msg336905 - (view) Author: Karthikeyan Singaravelan (xtreak) * (Python committer) Date: 2019-03-01 08:59
If I understand this correctly any combination that imports mock._ANY affects test_gc like below combination that uses mock._ANY causes test_gc to fail ? ./python.exe -m unittest unittest.test.testmock test.test_gc [snip output] ---------------------------------------------------------------------- Ran 404 tests in 8.551s FAILED (failures=1, skipped=1)
msg336906 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2019-03-01 09:08
Yup, I was actually using: ./python.exe -m test test_asyncio test_gc -m test_gc when I found out thst the core cause was mock._ANY :)
msg336907 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2019-03-01 09:12
New changeset d60a79a1015aa26ff7ee3166820ec43558911b60 by Pablo Galindo in branch 'master': bpo-36155: Check for identity on test_gc.test_get_objects (GH-12116) https://github.com/python/cpython/commit/d60a79a1015aa26ff7ee3166820ec43558911b60
msg336908 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2019-03-01 09:13
Ok, this one has been fun :) Thanks for finding this one @xtreak!
msg336909 - (view) Author: Karthikeyan Singaravelan (xtreak) * (Python committer) Date: 2019-03-01 09:19
No problem. Thanks for fix :) I stumbled upon it due to a typo where I used -m instead of -v in python -m test -m test_gc instead of python -m test -v test_gc . Any suggestion on how you debugged it was mock ?
msg336910 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2019-03-01 09:32
Well, unless there was a bug on the gc, the only way the list l could be on both lists is if in one of them there was something that was saying that is equal to it. To confirm I checked what was equal to l in the second generation and I saw it was mock.ANY :)
msg336911 - (view) Author: Karthikeyan Singaravelan (xtreak) * (Python committer) Date: 2019-03-01 09:45
Thanks for the explanation :)
History
Date User Action Args
2022-04-11 14:59:11 admin set github: 80336
2019-03-01 09:45:14 xtreak set messages: +
2019-03-01 09:32:04 pablogsal set messages: +
2019-03-01 09:19:46 xtreak set messages: +
2019-03-01 09:13:11 pablogsal set status: open -> closedresolution: fixedmessages: + stage: patch review -> resolved
2019-03-01 09:12:40 pablogsal set messages: +
2019-03-01 09:08:19 pablogsal set messages: +
2019-03-01 08:59:43 xtreak set messages: +
2019-03-01 08:53:38 pablogsal set keywords: + patchstage: patch reviewpull_requests: + <pull%5Frequest12122>
2019-03-01 08:48:20 pablogsal set messages: +
2019-03-01 08:15:21 pablogsal set messages: +
2019-03-01 08:14:45 pablogsal set messages: +
2019-03-01 07:57:27 pablogsal set messages: +
2019-03-01 07:29:13 xtreak create