FW: weird bug in test_winreg
Oops - I didnt notice the CC - a copy of what I sent to Guido: -----Original Message----- From: Mark Hammond [mailto:mhammond@skippinet.com.au] Sent: Thursday, 4 May 2000 11:13 AM To: Guido van Rossum Subject: RE: weird bug in test_winreg Hah - I was just thinking about this this myself. If I wasnt waiting 24 hours, I would have beaten you to the test_fork1 patch :-) However, there is something bad going on. If you remove your test_fork1 patch, and run it from regrtest (_not_ stand alone) you will see the children threads die with: File "L:\src\Python-cvs\Lib\test\test_fork1.py", line 30, in f alive[id] = os.getpid() AttributeError: 'None' object has no attribute 'getpid' Note the error - os is None! [The reason is only happens as part of the test is because the children are created before the main thread fails with the attribute error] Similarly, I get spurious: Traceback (most recent call last): File ".\test_thread.py", line 103, in task2 mutex.release() AttributeError: 'None' object has no attribute 'release' (Only rarely, and never when run stand-alone - the test_fork1 exception happens 100% of the time from the test suite) And of course the test_winreg one. test_winreg, I guessed, may be caused by the import lock (but its certainly not obvious how or why!?). However, that doesnt explain the others. I also saw these _before_ I applied the threading patches (and after!) So I think the problem may be a little deeper? Mark.
Mark Hammond:
However, there is something bad going on. If you remove your test_fork1 patch, and run it from regrtest (_not_ stand alone) you will see the children threads die with:
File "L:\src\Python-cvs\Lib\test\test_fork1.py", line 30, in f alive[id] = os.getpid() AttributeError: 'None' object has no attribute 'getpid'
Note the error - os is None!
[The reason is only happens as part of the test is because the children are created before the main thread fails with the attribute error]
I don't get this one -- maybe my machine is too slow. (130 MHz Pentium.)
Similarly, I get spurious:
Traceback (most recent call last): File ".\test_thread.py", line 103, in task2 mutex.release() AttributeError: 'None' object has no attribute 'release'
(Only rarely, and never when run stand-alone - the test_fork1 exception happens 100% of the time from the test suite)
And of course the test_winreg one.
test_winreg, I guessed, may be caused by the import lock (but its certainly not obvious how or why!?). However, that doesnt explain the others.
I also saw these _before_ I applied the threading patches (and after!)
So I think the problem may be a little deeper?
It's Vladimir's patch which, after each tests, unloads all modules that were loaded by that test. If I change this to only unload modules whose name starts with "test.", the test_winreg problem goes away, and I bet yours go away too. The real reason must be deeper -- there's also the import lock and the fact that if a submodule of package "test" tries to import "os", a search for "test.os" is made and if it doesn't find it it sticks None in sys.modules['test.os']. but I don't have time to research this further. I'm tempted to apply the following change to regrtest.py. This should still unload the test modules (so you can rerun an individual test) but it doesn't touch other modules. I'll wait 24 hours. :-) *** regrtest.py 2000/04/21 21:35:06 1.15 --- regrtest.py 2000/05/04 16:56:26 *************** *** 121,127 **** skipped.append(test) # Unload the newly imported modules (best effort finalization) for module in sys.modules.keys(): ! if module not in save_modules: test_support.unload(module) if good and not quiet: if not bad and not skipped and len(good) > 1: --- 121,127 ---- skipped.append(test) # Unload the newly imported modules (best effort finalization) for module in sys.modules.keys(): ! if module not in save_modules and module.startswith("test."): test_support.unload(module) if good and not quiet: if not bad and not skipped and len(good) > 1: --Guido van Rossum (home page: http://www.python.org/~guido/)
It's Vladimir's patch which, after each tests, unloads all modules that were loaded by that test. If I change this to only unload modules whose name starts with "test.", the test_winreg problem goes away, and I bet yours go away too.
They do indeed!
The real reason must be deeper -- there's also the import lock and the fact that if a submodule of package "test" tries to import "os", a search for "test.os" is made and if it doesn't find it it sticks None in sys.modules['test.os'].
but I don't have time to research this further.
I started to think about this. The issue is simply that code which blithely wipes sys.modules[] may cause unexpected results. While the end result is a bug, the symptoms are caused by extreme hackiness. Seeing as my time is also limited, I say we forget it!
I'm tempted to apply the following change to regrtest.py. This should still unload the test modules (so you can rerun an individual test) but it doesn't touch other modules. I'll wait 24 hours. :-)
The 24 hour time limit is only supposed to apply to _my_ patches - you can check yours straight in (and if anyone asks, just tell them I said it was OK) :-) Mark.
participants (2)
-
Guido van Rossum
-
Mark Hammond