1. 24 Apr, 2000 11 commits
  2. 23 Apr, 2000 5 commits
  3. 22 Apr, 2000 14 commits
  4. 21 Apr, 2000 10 commits
    • Jack Jansen's avatar
      ee081040
    • Guido van Rossum's avatar
    • Guido van Rossum's avatar
      Patch by Vladimir Marangozov to unload additionally imported modules · 5796d267
      Guido van Rossum authored
      after each test has been run.  This avoids excessive memory growth
      during the tests.
      5796d267
    • Guido van Rossum's avatar
      Added test_winsound by Mark Hammond. · cdd092fe
      Guido van Rossum authored
      cdd092fe
    • Guido van Rossum's avatar
      Mark Hammond: · a8ee4c31
      Guido van Rossum authored
      * Base address for all extension modules updated. PC\dllbase_nt.txt
      also updated.  Erroneous "libpath" directory removed for all
      projects.
      
      * winsound module moved from a builtin module to an extension
      module.  This was done primarily to avoid Python16.dll needing to
      pull in winmm.dll.  Really dumb test added for winsound - but if
      nothing else it ensures the module imports.
      a8ee4c31
    • Guido van Rossum's avatar
      Mark Hammond: · 7053b8a4
      Guido van Rossum authored
      * Temp directory for all projects are now specific to the project
      (rather than common as before).  This avoids any conflicts with
      debug symbols or common file names etc.
      NOTE: You should manually delete your existing build directory after
      applying this patch, as the MSVC "clean" command will now only clean
      the new temporary directories - not the existing common temp
      directory.
      
      * Base address for all extension modules updated. PC\dllbase_nt.txt
      also updated.  Erroneous "libpath" directory removed for all
      projects.
      
      * winsound module moved from a builtin module to an extension
      module.  This was done primarily to avoid Python16.dll needing to
      pull in winmm.dll.  Really dumb test added for winsound - but if
      nothing else it ensures the module imports.
      7053b8a4
    • Guido van Rossum's avatar
      Charles Waldman writes: · 25826c93
      Guido van Rossum authored
      """
      Running "test_extcall" repeatedly results in memory leaks.
      
      One of these can't be fixed (at least not easily!), it happens since
      this code:
      
      def saboteur(**kw):
          kw['x'] = locals()
      d = {}
      saboteur(a=1, **d)
      
      creates a circular reference - d['x']['d']==d
      
      The others are due to some missing decrefs in ceval.c, fixed by the
      patch attached below.
      
      Note:  I originally wrote this without the "goto", just adding the
      missing decref's where needed.  But I think the goto is justified in
      keeping the executable code size of ceval as small as possible.
      """
      
      [I think the circular reference is more like kw['x']['kw'] == kw. --GvR]
      25826c93
    • Guido van Rossum's avatar
      Patch by Charles G Waldman to avoid a sneaky memory leak in · 5ce78f8e
      Guido van Rossum authored
      _PyTuple_Resize().  In addition, a change suggested by Jeremy Hylton
      to limit the size of the free lists is also merged into this patch.
      
      Charles wrote initially:
      
      """
      Test Case:  run the following code:
      
      class Nothing:
          def __len__(self):
              return 5
          def __getitem__(self, i):
              if i < 3:
                  return i
              else:
                  raise IndexError, i
      
      def g(a,*b,**c):
          return
      
      for x in xrange(1000000):
          g(*Nothing())
      
      
      and watch Python's memory use go up and up.
      
      
      Diagnosis:
      
      The analysis begins with the call to PySequence_Tuple at line 1641 in
      ceval.c - the argument to g is seen to be a sequence but not a tuple,
      so it needs to be converted from an abstract sequence to a concrete
      tuple.  PySequence_Tuple starts off by creating a new tuple of length
      5 (line 1122 in abstract.c).  Then at line 1149, since only 3 elements
      were assigned, _PyTuple_Resize is called to make the 5-tuple into a
      3-tuple.  When we're all done the 3-tuple is decrefed, but rather than
      being freed it is placed on the free_tuples cache.
      
      The basic problem is that the 3-tuples are being added to the cache
      but never picked up again, since _PyTuple_Resize doesn't make use of
      the free_tuples cache.  If you are resizing a 5-tuple to a 3-tuple and
      there is already a 3-tuple in free_tuples[3], instead of using this
      tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple.  It
      would more efficient to use the existing 3-tuple and cache the
      5-tuple.
      
      By making _PyTuple_Resize aware of the free_tuples (just as
      PyTuple_New), we not only save a few calls to realloc, but also
      prevent this misbehavior whereby tuples are being added to the
      free_tuples list but never properly "recycled".
      """
      
      And later:
      
      """
      This patch replaces my submission of Sun, 16 Apr and addresses Jeremy
      Hylton's suggestions that we also limit the size of the free tuple
      list.  I chose 2000 as the maximum number of tuples of any particular
      size to save.
      
      There was also a problem with the previous version of this patch
      causing a core dump if Python was built with Py_TRACE_REFS.  This is
      fixed in the below version of the patch, which uses tupledealloc
      instead of _Py_Dealloc.
      """
      5ce78f8e
    • Guido van Rossum's avatar
      Charles Waldman writes: · 84219682
      Guido van Rossum authored
      """
      In the course of debugging this I also saw that cPickle is
      inconsistent with pickle - if you attempt a pickle.load or pickle.dump
      on a closed file, you get a ValueError, whereas the corresponding
      cPickle operations give an IOError.  Since cPickle is advertised as
      being compatible with pickle, I changed these exceptions to match.
      """
      84219682
    • Guido van Rossum's avatar
      Charles Waldman writes: · 83addc7a
      Guido van Rossum authored
      """
      Problem description:
      
      	Run the following script:
      
      import test.test_cpickle
      for x in xrange(1000000):
          reload(test.test_cpickle)
      
      Watch Python's memory use go up up and away!
      
      In the course of debugging this I also saw that cPickle is
      inconsistent with pickle - if you attempt a pickle.load or pickle.dump
      on a closed file, you get a ValueError, whereas the corresponding
      cPickle operations give an IOError.  Since cPickle is advertised as
      being compatible with pickle, I changed these exceptions to match.
      """
      83addc7a