1. 29 Oct, 2004 2 commits
  2. 18 Oct, 2004 1 commit
    • Tim Peters's avatar
      Collector 1542: Python 2.4/Zope 2.8 unittest failure in asyncore.py · b11eabb7
      Tim Peters authored
      Forward port form 2.7 branch.
      
      medusa's class monitor_server derives from asyncore.dispatcher, but
      never called the latter's constructor.  As a result, the ._map attribute
      set by 2.4's asyncore.dispatcher.__init__() never gets set, and calling
      asyncore methods later dies with an AttributeError on ._map.  The fix
      is a 1-liner, adding a call to the base-class constructor.
      b11eabb7
  3. 17 Oct, 2004 1 commit
  4. 15 Oct, 2004 4 commits
  5. 14 Oct, 2004 2 commits
  6. 13 Oct, 2004 1 commit
  7. 12 Oct, 2004 4 commits
  8. 11 Oct, 2004 1 commit
  9. 10 Oct, 2004 1 commit
  10. 09 Oct, 2004 1 commit
  11. 08 Oct, 2004 2 commits
    • Tim Peters's avatar
      Gentler treatment for issue #1350. · 3f0db85b
      Tim Peters authored
      The Python fatal errors occur only in a debug build now.
      
      In a release build, unghostify() raises a Python SystemError
      exception if it detects insanity, and ghostify() ignores the
      problem (as ZODB 3.2 did, although it looks like 3.2 ignored
      the problem by mistake).  This isn't *good*, because the
      system is insane.  But it can become insane only by breaking
      absolute threading rules, and that "should never happen".
      Unfortunately, hundreds of things can go wrong if it does
      happen, and we can't detect most of them.
      3f0db85b
    • Tim Peters's avatar
      Extreme sanction for collector #1350. · 17c89bd8
      Tim Peters authored
      In ghostify() and unghostify(), trigger a fatal error if the
      object is insane.  This prevents a segfault (or, worse, arbitrary
      memory corruption) later.
      
      The test suite isn't bothered by this, and neither is bringing
      up a Zope and playing around with it.  The only known cause
      appears to be threading problems related to Transience.py,
      partly explained in issue #1350.  It should be impossible for
      these fatal errors to trigger via thread-correct use of ZODB.
      
      I don't expect to keep these fatal errors in the code; indeed,
      I'm checking this in only in Zope's *copy* of ZODB.  The intent
      is to help whoever can make time for 1350 know whether that
      problem still exists, until that problem goes away.  Unfortunately,
      it's not even possible to raise an exception from ghostify()
      (it's a void routine that "can't fail"), so it takes an extreme
      measure to catch the problem as soon as it's visible.
      17c89bd8
  12. 06 Oct, 2004 2 commits
  13. 05 Oct, 2004 2 commits
  14. 04 Oct, 2004 3 commits
  15. 01 Oct, 2004 2 commits
  16. 30 Sep, 2004 7 commits
  17. 28 Sep, 2004 3 commits
  18. 27 Sep, 2004 1 commit