Re: [Python-Dev] test_bigmem and test_bigaddrspace broken
Hello, Le mercredi 17 mars 2010 à 11:58 -0700, C. Titus Brown a écrit :
On Wed, Mar 17, 2010 at 06:54:33PM +0000, Antoine Pitrou wrote:
The title says it all. test_bigmem and test_bigaddrspace are partly broken under py3k, and no buildbot ever tests that they run successfully. As an example, here is a test_bigmem run under a 16GB machine. It gets "killed" at some point, probably by the Linux kernel's OOM killer, although I instruct the test suite to only use a fraction of the available RAM. There are also a couple of failures:
I can provide login access to a 24gb machine (Linux), if you or others are interested. Sometimes it's running other stuff, but it's got lots of swap :)
Thanks for the proposal. That wasn't really the point of my message, though :) As mentioned I have access to a 16GB machine which is able to run the tests. The problem is that nobody seems interested in maintaining these tests. As far as I can say, the initial committer is Thomas Wouters, and not much happened since then. It seems to me that big companies such as Google and Apple would be the primarily concerned ones by such scenarios, and willing to ensure they run fine. (by the way, even without swapping and in non-debug mode, the tests are quite long to run) Regards Antoine.
As mentioned I have access to a 16GB machine which is able to run the tests. The problem is that nobody seems interested in maintaining these tests.
So what do you propose to do? I personally don't see that as a problem. Many rarely-used features get infrequent testing - that's the nature of rarely-used features. In turn, they tend to break over time, until somebody comes along and fixes them. That's open source: scratch your own itches.
As far as I can say, the initial committer is Thomas Wouters, and not much happened since then. It seems to me that big companies such as Google and Apple would be the primarily concerned ones by such scenarios, and willing to ensure they run fine.
I'm not sure Apple has really Python applications running that use a lot of memory - being a big company doesn't necessarily mean you operate large machines. I'm sure Google has applications that use that much memory, and I wouldn't be surprised if Google has also bug fixes for various bugs in large objects that they haven't been contributing (yet). In any case, I think it's a good thing that these tests are there for people to run if they have the hardware and the time. If somebody wanted to contribute such hardware as a build slave - that could certainly be arranged. Regards, Martin
Martin v. Löwis <martin <at> v.loewis.de> writes:
As mentioned I have access to a 16GB machine which is able to run the tests. The problem is that nobody seems interested in maintaining these tests.
So what do you propose to do?
Nothing. I was pointing out the issue here because it is not obvious that interested people would follow tracker updates. Of course, there is also the problem of having tests which never get run and whose failures don't get noticed (test_zipfile64 is another example, although the last time I tried it ran ok). And the additional problem of buggy tests (test_bigmem shouldn't OOM if I ask it to use 8GB on a machine with around 14GB of free mem). Regards Antoine.
participants (2)
-
"Martin v. Löwis" -
Antoine Pitrou