[ python-Bugs-857909 ] bsddb craps out sporadically
Bugs item #857909, was opened at 2003-12-10 14:41 Message generated for change (Comment added) made by brandonh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857909&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.3 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Predrag Miocinovic (predragm) Assigned to: Gregory P. Smith (greg) Summary: bsddb craps out sporadically Initial Comment: I get following from Python2.3.2 with BerkeleyDB 3.3.11 running on linux RH7.3; Traceback (most recent call last): File "/raid/ANITA-lite/gse/unpackd.py", line 702, in ? PacketObject.shelve() File "/raid/ANITA-lite/gse/unpackd.py", line 78, in shelve wvShelf[shelfKey] = self File "/usr/local/lib/python2.3/shelve.py", line 130, in __setitem__ self.dict[key] = f.getvalue() File "/usr/local/lib/python2.3/bsddb/__init__.py", line 120, in __setitem__ self.db[key] = value bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery -- PANIC: Invalid argument') Exception bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery') in ignored Exception bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery') in ignored -- The server reporting this is running at relatively heavy load and the error occurs several times per day (this call occurs roughly 100,000 per day, but only 42 times per any given shelve instance). It reminds be of bug report #775414, but this is a non-threaded application. That said, another process is accessing the same shelve, but I've implemented a lockout system which should make sure they don't have simultaneous access. The lockout seems to work fine. The same application is running on different machine using Python2.3.2 with BerkeleyDB 4.0.14 on linux RH9 and the same error occured once (to my knowledge), but with "30987" replaced by "30981" in the traceback above, if it makes any difference. Finally, a third system, python2.3.2 with BerkeleyDB 4.0.14 on linux RH9 (but quite a bit faster, and thus lighter load) runs w/o reporting this problem so far. I don't have a convenient code snipet to exemplify the problem, but I don't do anything more than open (or re-open) a shelve and write a single python object instance to it per opening. If necessary, I can provide the code in question. -- Comment By: Brandon Hechinger (brandonh) Date: 2005-12-08 01:33 Message: Logged In: YES user_id=226421 We also get this error, though not using Python, but C. I'm not sure why people are so eager to dismiss it as an issue here, however, for it might be something your Python is doing with the Berkeley DB interface which could be improved. In our case, there is a similarity -- the site accesses the database(s) at relatively high frequency, and we use our own locking system to prevent any conflict (allowing multiple readers and exclusive writers -- writers not so much as generating a path to the database, let alone opening it, until they obtain the separate lock handled by our software). Periodically one of the databases will have an error when reading a key, and this error will remain until the database is repaired. The error return code is -30987. It's not 100% conclusive if it happens primarily on frequently accessed databases or not, and were it the case, it is not clear whether that's just because it occurs because of the high volume of access, or just because their volume increases the likelihood of encountering an error. In any case, our locking mechanisms (we've tried more than one) do lock prior to the database being opened at all, and are handled in a multi-reader single-writer way. Again, it's not clear if it's a Berkeley DB problem, or a problem with the *way* we are accessing/using Berkeley DB. Until this is known, I don't think it should be so quickly blown off that it's not a Python issue -- even if a bit of resources of the Python resources went into finding a Berkeley DB problem, would it result in such a bad world? :) -- Comment By: Gregory P. Smith (greg) Date: 2004-06-16 15:50 Message: Logged In: YES user_id=413 DB_RUNRECOVERY errors are a sleepycat BerkeleyDB internal error and don't have anything to do with the python library wrapper. For help in tracking them down I suggest using the latest BerkeleyDB version and ask with example code on the berkeleydb newsgroups or ask sleepycat themselves (they don't bite, they're friendly). closing this bug as its not a python or extension module bug. If you're looking for a multiprocess aware BerkeleyDB shelve
[ python-Bugs-1163563 ] Sub threads execute in restricted mode
Bugs item #1163563, was opened at 2005-03-15 03:56 Message generated for change (Comment added) made by alephant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 8 Submitted By: anothermax (yetanothermax) Assigned to: Michael Hudson (mwh) Summary: Sub threads execute in restricted mode Initial Comment: I'm using the JEP product which allows integration of Java with Python (see http://jepp.sourceforge.net) via starting a Python interpreter in the same process as the JVM. This integrates with python via the C interface, allowing the user to 'eval' python code (amongst other features). It seems that since Python 2.3.5 any threads (using the threading module) created via code that has been evaluated through the jep.eval() interface (i.e.Python C interface )are executed in restricted mode and cannot, for example, create files. Code that is just evaled (i.e not in a subthread) thread has no restrictions. The error reported is: IOError: file() constructor not accessible in restricted mode (see http://sourceforge.net/forum/forum.php? thread_id=1247793&forum_id=376782) - I've given a JEP specific example here. There seems to be a similar problem with mod_python (see http://www.modpython.org/pipermail/mod_python/2005- January/017129.html) Reading through the release notes for Python 2.3.5 I see: Bug #754449: threading.Thread will no longer mask exceptions raised during interpreter shutdown with another exception caused by attempting to output the initial exception. This fix also includes a backport of rev. 1.41 from HEAD. This might be the problem as it seems to involve the porting of 2.4 threading code back to the 2.3 tree. I've attached a Java file which shows the problem when using JEP. The error output is: Exception in thread Thread-1: Traceback (most recent call last): File "C:\Python24\Lib\threading.py", line 442, in __bootstrap File "", line 5, in run IOError: file() constructor not accessible in restricted mode 2.4.1c1 (#63, Mar 10 2005, 10:36:41) [MSC v.1310 32 bit (Intel)] Creating file from main thread... Done Creating file from sub thread... Done -- Comment By: Christopher DeMarco (alephant) Date: 2005-12-08 07:49 Message: Logged In: YES user_id=1400247 This is apparantly fixed in 2.4.2 despite the absence of an entry in the NEWS for that release. -- Comment By: Michael Hudson (mwh) Date: 2005-06-20 12:54 Message: Logged In: YES user_id=6656 Fixed, in Misc/NEWS revision 1.1301 Modules/threadmodule.c revision 2.64 Python/pystate.c revision 2.42 (I made a tiny tweak in addition to the latest patch attached to this report). yetanothermax: Thanks for the report, and the testing of patches! -- Comment By: anothermax (yetanothermax) Date: 2005-06-17 10:37 Message: Logged In: YES user_id=1218811 The maybe-even-better-1010677-fix also seems to work -- Comment By: Michael Hudson (mwh) Date: 2005-06-17 08:10 Message: Logged In: YES user_id=6656 That's good to hear. Tim: could you glance over the attached? If you can't be assed to read all the various reports, I've attempted to summarise the problem(s) here: http://mail.python.org/pipermail/python-dev/2005-June/054258.html If you don't have time, please at least say so... yetanothermax: thanks for the confirmation. Could you also try this cleaner version of the patch? Wrt your patch, it took me too long to work out that it was simply unapplying the earlier changes -- and you don't need to supply a patch for that, even creaky old CVS makes *that* easy :) -- Comment By: anothermax (yetanothermax) Date: 2005-06-17 06:35 Message: Logged In: YES user_id=1218811 Good news - I've made a couple of tests and the patch seems to fix the problem. With regards to the earlier patch: - apologies for not running the test suite - I feel suitably chastised :) & I'll be sure to run it in the future. - I did note that it would probably re-raise #1010677 (see 2005-04-20 13:51 comment) but guessed it was more important to contribute the patch so that someone who has better thread implementation knowledge could look into it... -- Comment By: Michael Hudson (mwh) Date: 2005-06-16 08:39 Message: Logged In: YES user_id=6656 So here's my take on a fix to 1010677, relative to CVS HEAD. It's something of a ha
[ python-Bugs-857909 ] bsddb craps out sporadically
Bugs item #857909, was opened at 2003-12-10 16:41 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857909&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.3 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Predrag Miocinovic (predragm) Assigned to: Gregory P. Smith (greg) Summary: bsddb craps out sporadically Initial Comment: I get following from Python2.3.2 with BerkeleyDB 3.3.11 running on linux RH7.3; Traceback (most recent call last): File "/raid/ANITA-lite/gse/unpackd.py", line 702, in ? PacketObject.shelve() File "/raid/ANITA-lite/gse/unpackd.py", line 78, in shelve wvShelf[shelfKey] = self File "/usr/local/lib/python2.3/shelve.py", line 130, in __setitem__ self.dict[key] = f.getvalue() File "/usr/local/lib/python2.3/bsddb/__init__.py", line 120, in __setitem__ self.db[key] = value bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery -- PANIC: Invalid argument') Exception bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery') in ignored Exception bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery') in ignored -- The server reporting this is running at relatively heavy load and the error occurs several times per day (this call occurs roughly 100,000 per day, but only 42 times per any given shelve instance). It reminds be of bug report #775414, but this is a non-threaded application. That said, another process is accessing the same shelve, but I've implemented a lockout system which should make sure they don't have simultaneous access. The lockout seems to work fine. The same application is running on different machine using Python2.3.2 with BerkeleyDB 4.0.14 on linux RH9 and the same error occured once (to my knowledge), but with "30987" replaced by "30981" in the traceback above, if it makes any difference. Finally, a third system, python2.3.2 with BerkeleyDB 4.0.14 on linux RH9 (but quite a bit faster, and thus lighter load) runs w/o reporting this problem so far. I don't have a convenient code snipet to exemplify the problem, but I don't do anything more than open (or re-open) a shelve and write a single python object instance to it per opening. If necessary, I can provide the code in question. -- >Comment By: Skip Montanaro (montanaro) Date: 2005-12-08 07:36 Message: Logged In: YES user_id=44345 > We also get this error, though not using Python, but C. > I'm not sure why people are so eager to dismiss it as an > issue here, however, for it might be something your Python > is doing with the Berkeley DB interface which could be > improved. The anydbm module was written long before Berkeley DB supported any sort of adequate locking mechanisms (in the BDB 1.85 days). It also supports multiple backends (dbm and gdbm in particular). The API it present to the user is of little more than a dictionary that happens to be stored on-disk. To change its API at this point to use bsddb's (and underlying it, BDB's) locking mechanisms is impossible, as neither of the other underlying db backends supports locking. The right thing for the author to do in this case is probably to use the new bsddb module directly and take advantage of its locking features. The shelve module's functionality would be trivial to implement on top of that. All it really does is transparently pickle the data written to the disk. -- Comment By: Brandon Hechinger (brandonh) Date: 2005-12-08 03:33 Message: Logged In: YES user_id=226421 We also get this error, though not using Python, but C. I'm not sure why people are so eager to dismiss it as an issue here, however, for it might be something your Python is doing with the Berkeley DB interface which could be improved. In our case, there is a similarity -- the site accesses the database(s) at relatively high frequency, and we use our own locking system to prevent any conflict (allowing multiple readers and exclusive writers -- writers not so much as generating a path to the database, let alone opening it, until they obtain the separate lock handled by our software). Periodically one of the databases will have an error when reading a key, and this error will remain until the database is repaired. The error return code is -30987. It's not 100% conclusive if it happens primarily on frequently accessed databases or not, and were it the case, it is not clear whether that's just because it occurs because of the high volume of access, or just because their volum
[ python-Feature Requests-816628 ] request for bugs.python.org
Feature Requests item #816628, was opened at 2003-10-02 11:55 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=816628&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Philippe Fremy (pfremy) >Assigned to: A.M. Kuchling (akuchling) Summary: request for bugs.python.org Initial Comment: Many projects (gentoo, gnome, kde...) have the conveninent url for accessing the bug database: bugs.python.org That would be cool. -- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-08 08:46 Message: Logged In: YES user_id=11375 I don't know if Thomas looks at things in the Python bug tracker. I've written him directly, asking for bugs.python.org to be created, and will do the Apache tweaking once the name has been created. -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-01-02 09:15 Message: Logged In: YES user_id=12800 I agree that this is a good idea, and easy to do. Let's add this hostname, point it at www.python.org, then set up an Apache rewrite rule to redirect to http://sourceforge.net/tracker/?group_id=5470&atid=105470 Assigning to Thomas for the dns tricks. I'll be happy to handle the Apache set up once the hostname has been added. -- Comment By: Philippe Fremy (pfremy) Date: 2004-01-01 10:15 Message: Logged In: YES user_id=233844 The goal is not to duplicate the sf page, just to provide an easier way to find it. bugs.python.org is very convenient and easy to remember. It saves time for the people reporting bugs because one does not have to skim through the 100 links of www.python.org to find where to report bugs. Other projects have adpoted it with success. There is nothing to lose by providing this shortcut. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 01:39 Message: Logged In: YES user_id=80475 We now own the domain, but I don't see an advantage to duplicating what is on SF. The main website at www.python.org has a direct link on the main page. IMO, that is enough. -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-10-02 12:15 Message: Logged In: YES user_id=12800 Even if it's a good idea, we can't do this until the PSF controls the python.org domain. I don't know what the status of that is, but I believe a transfer is in the works. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=816628&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1376292 ] Write user's version of RefGuide
Feature Requests item #1376292, was opened at 2005-12-08 08:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1376292&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: A.M. Kuchling (akuchling) Summary: Write user's version of RefGuide Initial Comment: The Reference Guide is very detailed and difficult to read, but nothing else documents things like statements or special object methods. We should have a shorter, friendlier guide to the syntax and basic types. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1376292&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1376309 ] subprocess.CalledProcessError uses errno incorrectly
Bugs item #1376309, was opened at 2005-12-08 09:14 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376309&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: None >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.CalledProcessError uses errno incorrectly Initial Comment: I have some code which uses subprocess.check_call(), which is buried in other code that catches an OSError, and does different things depending on OSError.errno. Since subprocess.CalledProcessError overloads errno for its own return code values, this leads to confusing error messages. The return code is NOT an errno, and I do not think this field should be overloaded in this way. Additionally, since OSError exceptions generally have an errno attribute set, and exception-handling code expects this, I do not think that CalledProcessError should subclass from it. -- Comment By: Michael Hoffman (hoffmanm) Date: 2005-12-08 09:27 Message: Logged In: YES user_id=987664 Ugh, this was supposed to be a bug, not a patch. Is there anyway to change this or should I just resumbit? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376309&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1349316 ] xmlrpclib does not use http proxy
Bugs item #1349316, was opened at 2005-11-05 21:07 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349316&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: John Beisley (greatred) Assigned to: A.M. Kuchling (akuchling) Summary: xmlrpclib does not use http proxy Initial Comment: The xmlrpclib class ServerProxy does not seem to be able to make use of a HTTP proxy. This makes it unusable behind a firewall where the proxy is the only access to the destination server. -- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-08 09:55 Message: Logged In: YES user_id=11375 Documentation changed in rev. 41636. Thanks! (Closing this bug, on the assumption that there's nothing further to be done.) -- Comment By: A.M. Kuchling (akuchling) Date: 2005-12-04 13:16 Message: Logged In: YES user_id=11375 I have a documentation change ready to go; will check that in once I get permission. -- Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 05:32 Message: Logged In: YES user_id=38376 To handle this, you can use a custom transport. Here's an example: http://lowlife.jp/nobonobo/wiki/xmlrpcwithproxy.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349316&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1376400 ] test_struct crashed, py2.3.5, solaris 10
Bugs item #1376400, was opened at 2005-12-08 17:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376400&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: rrogans (rrogans) Assigned to: Nobody/Anonymous (nobody) Summary: test_struct crashed, py2.3.5, solaris 10 Initial Comment: Hi, I am building python 2.3.5 on solaris 10 using gcc 3.3.2. Run I perform the test I get one test failure - test_struct crashes. Rgds, Richard trying std qQ on 1471797217424382203 == 0x146CDFC575FD18FBL trying std qQ on 1471797217424382204 == 0x146CDFC575FD18FCL trying std qQ on 1471797217424382205 == 0x146CDFC575FD18FDL test test_struct crashed -- exceptions.OverflowError: math range error Traceback (most recent call last): File "./Lib/test/regrtest.py", line 394, in runtest the_package = __import__(abstest, globals(), locals (), []) File "/home/richardr/app/Python- 2.3.5/Lib/test/test_struct.py", line 439, in ? test_705836() File "/home/richardr/app/Python- 2.3.5/Lib/test/test_struct.py", line 424, in test_705836 big = math.ldexp(big, 127 - 23) OverflowError: math range error 1 test failed: test_struct <<< -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376400&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-857909 ] bsddb craps out sporadically
Bugs item #857909, was opened at 2003-12-10 14:41 Message generated for change (Comment added) made by brandonh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857909&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.3 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Predrag Miocinovic (predragm) Assigned to: Gregory P. Smith (greg) Summary: bsddb craps out sporadically Initial Comment: I get following from Python2.3.2 with BerkeleyDB 3.3.11 running on linux RH7.3; Traceback (most recent call last): File "/raid/ANITA-lite/gse/unpackd.py", line 702, in ? PacketObject.shelve() File "/raid/ANITA-lite/gse/unpackd.py", line 78, in shelve wvShelf[shelfKey] = self File "/usr/local/lib/python2.3/shelve.py", line 130, in __setitem__ self.dict[key] = f.getvalue() File "/usr/local/lib/python2.3/bsddb/__init__.py", line 120, in __setitem__ self.db[key] = value bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery -- PANIC: Invalid argument') Exception bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery') in ignored Exception bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery') in ignored -- The server reporting this is running at relatively heavy load and the error occurs several times per day (this call occurs roughly 100,000 per day, but only 42 times per any given shelve instance). It reminds be of bug report #775414, but this is a non-threaded application. That said, another process is accessing the same shelve, but I've implemented a lockout system which should make sure they don't have simultaneous access. The lockout seems to work fine. The same application is running on different machine using Python2.3.2 with BerkeleyDB 4.0.14 on linux RH9 and the same error occured once (to my knowledge), but with "30987" replaced by "30981" in the traceback above, if it makes any difference. Finally, a third system, python2.3.2 with BerkeleyDB 4.0.14 on linux RH9 (but quite a bit faster, and thus lighter load) runs w/o reporting this problem so far. I don't have a convenient code snipet to exemplify the problem, but I don't do anything more than open (or re-open) a shelve and write a single python object instance to it per opening. If necessary, I can provide the code in question. -- Comment By: Brandon Hechinger (brandonh) Date: 2005-12-08 09:31 Message: Logged In: YES user_id=226421 We also get this error, though not using Python, but C. I'm not sure why people are so eager to dismiss it as an issue here, however, for it might be something your Python is doing with the Berkeley DB interface which could be improved. In our case, there is a similarity -- the site accesses the database(s) at relatively high frequency, and we use our own locking system to prevent any conflict (allowing multiple readers and exclusive writers -- writers not so much as generating a path to the database, let alone opening it, until they obtain the separate lock handled by our software). Periodically one of the databases will have an error when reading a key, and this error will remain until the database is repaired. The error return code is -30987. It's not 100% conclusive if it happens primarily on frequently accessed databases or not, and were it the case, it is not clear whether that's just because it occurs because of the high volume of access, or just because their volume increases the likelihood of encountering an error. In any case, our locking mechanisms (we've tried more than one) do lock prior to the database being opened at all, and are handled in a multi-reader single-writer way. Again, it's not clear if it's a Berkeley DB problem, or a problem with the *way* we are accessing/using Berkeley DB. Until this is known, I don't think it should be so quickly blown off that it's not a Python issue -- even if a bit of resources of the Python resources went into finding a Berkeley DB problem, would it result in such a bad world? :) -- Comment By: Skip Montanaro (montanaro) Date: 2005-12-08 05:36 Message: Logged In: YES user_id=44345 > We also get this error, though not using Python, but C. > I'm not sure why people are so eager to dismiss it as an > issue here, however, for it might be something your Python > is doing with the Berkeley DB interface which could be > improved. The anydbm module was written long before Berkeley DB supported any sort of adequate locking mechanisms (in the BDB 1.85 days). It also supports multiple backends (dbm and gdbm in particular). Th
[ python-Feature Requests-816628 ] request for bugs.python.org
Feature Requests item #816628, was opened at 2003-10-02 11:55 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=816628&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Philippe Fremy (pfremy) Assigned to: A.M. Kuchling (akuchling) Summary: request for bugs.python.org Initial Comment: Many projects (gentoo, gnome, kde...) have the conveninent url for accessing the bug database: bugs.python.org That would be cool. -- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-08 12:54 Message: Logged In: YES user_id=11375 bugs.python.org has been created; I've set up Apache to redirect it to the top page of the bug tracker. http://bugs.python.org/ redirects to the specific bug, same as http://python.org/sf/. -- Comment By: A.M. Kuchling (akuchling) Date: 2005-12-08 08:46 Message: Logged In: YES user_id=11375 I don't know if Thomas looks at things in the Python bug tracker. I've written him directly, asking for bugs.python.org to be created, and will do the Apache tweaking once the name has been created. -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-01-02 09:15 Message: Logged In: YES user_id=12800 I agree that this is a good idea, and easy to do. Let's add this hostname, point it at www.python.org, then set up an Apache rewrite rule to redirect to http://sourceforge.net/tracker/?group_id=5470&atid=105470 Assigning to Thomas for the dns tricks. I'll be happy to handle the Apache set up once the hostname has been added. -- Comment By: Philippe Fremy (pfremy) Date: 2004-01-01 10:15 Message: Logged In: YES user_id=233844 The goal is not to duplicate the sf page, just to provide an easier way to find it. bugs.python.org is very convenient and easy to remember. It saves time for the people reporting bugs because one does not have to skim through the 100 links of www.python.org to find where to report bugs. Other projects have adpoted it with success. There is nothing to lose by providing this shortcut. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 01:39 Message: Logged In: YES user_id=80475 We now own the domain, but I don't see an advantage to duplicating what is on SF. The main website at www.python.org has a direct link on the main page. IMO, that is enough. -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-10-02 12:15 Message: Logged In: YES user_id=12800 Even if it's a good idea, we can't do this until the PSF controls the python.org domain. I don't know what the status of that is, but I believe a transfer is in the works. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=816628&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1376309 ] subprocess.CalledProcessError uses errno incorrectly
Bugs item #1376309, was opened at 2005-12-08 15:14 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376309&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) >Assigned to: Peter Åstrand (astrand) Summary: subprocess.CalledProcessError uses errno incorrectly Initial Comment: I have some code which uses subprocess.check_call(), which is buried in other code that catches an OSError, and does different things depending on OSError.errno. Since subprocess.CalledProcessError overloads errno for its own return code values, this leads to confusing error messages. The return code is NOT an errno, and I do not think this field should be overloaded in this way. Additionally, since OSError exceptions generally have an errno attribute set, and exception-handling code expects this, I do not think that CalledProcessError should subclass from it. -- Comment By: Michael Hoffman (hoffmanm) Date: 2005-12-08 15:27 Message: Logged In: YES user_id=987664 Ugh, this was supposed to be a bug, not a patch. Is there anyway to change this or should I just resumbit? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376309&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-689895 ] Imports can deadlock
Bugs item #689895, was opened at 2003-02-20 00:39 Message generated for change (Comment added) made by sitbon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=689895&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Nobody/Anonymous (nobody) Summary: Imports can deadlock Initial Comment: [Just copying some discussion details from python-dev into this bug report so that we can reopen it to Python 2.4] [MAL] >> I wonder whether a general lock such as the one used in import >> is such a good idea. Perhaps it should only lock the importing >> of a specific module, keeping the locks in a dictionary indexed by >> module name instead of a static C variable ?! I've been thinking along the same lines. We could make the import locking much finer-grained, and limit the blocking only to threads that are importing a module that is in the middle of being loaded by some other thread. But this is hard work, and I suggest that we put this off until Python 2.4 so we can do it right. >> Then again it's hard to know the real name of the module being >> searched before finding it... There could be a short-lived lock for that problem. >> I see a more general problem here: the lock prevent starting >> up threaded applications which use client-server logic between >> the threads. If the application's main thread starts a client >> thread as a result of an import which then tries to import >> other Python modules, you have a deadlock. (At least that's how >> I understand the current implementation.) Correct. >> Don't know about others, but I frequently use the idiom of >> placing the server's main code in a separate module and then >> have small startup script importing this module. This kind >> of setup is also advertised for CGI programs, so it may not >> be uncommon out there. We had this problem with Zope2 -- I don't know why the import lock didn't bite us before, but we decided to change the Zope startup code so that you have to import Zope first and then, separately, make a call to start it. You could do the same for your application, and I recommend that Mark does the same for his. --Guido van Rossum (home page: http://www.python.org/~guido/) -- Comment By: Phillip Sitbon (sitbon) Date: 2005-12-08 13:50 Message: Logged In: YES user_id=1303233 Has anyone looked further into this? I seem to be having the same problem with a simple multithreaded program that imports from within thread functions. I didn't have the problem (at least not too often, but still in some cases) with 2.4.1 but now 2.4.2 has me deadlocking on the imports every time. It's a frustrating problem! -- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-20 00:40 Message: Logged In: YES user_id=38388 [EMAIL PROTECTED] >[MAL] > >>> > I wonder whether a general lock such as the one used in import >>> > is such a good idea. Perhaps it should only lock the importing >>> > of a specific module, keeping the locks in a dictionary indexed by >>> > module name instead of a static C variable ?! I am interested in this also. >> >> [Guido] >> I've been thinking along the same lines. We could make the import >> locking much finer-grained, and limit the blocking only to threads >> that are importing a module that is in the middle of being loaded by >> some other thread. >> >> But this is hard work, and I suggest that we put this off until Python >> 2.4 so we can do it right. I ran into this exact thing when trying to get wxPython windows (data plots) to co-exist peacefully on the screen in parallel with an interactive shell. The module is called gui_thread, and we use it in SciPy. http://www.scipy.org/site_content/tutorials/gui_thread The command line took the main thread, and a wxPython app was started in the background thread. The first import of wxPython had to occur in the background thread for wxPython's to be happy. Initially, I put a lock in the import of gui_thread which waited for the wxPython import to complete before allowing the gui_thread import to complete. If 'import gui_thread' is the first statement executed, this guarantees that wxPython is always imported first in the background thread. Unfortunately, it also causes deadlock because of the import lock. A discussion that occurred about this problem on the thread-sig with is summarized here: http://www.scipy.org/site_content/tutorials/import_thread_lock_discussio n It includes an alternative version of several import.c routines (compared to 1.5.2 I believe) that solved my problem as proposed by MAL above and passed
[ python-Bugs-1376775 ] Memory leak in the email package
Bugs item #1376775, was opened at 2005-12-08 17:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: ken668 (ken668)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory leak in the email package
Initial Comment:
memory leak in email.message_from_string. This is what
I did to create a leak.
You used the attached file, memleak.eml.
f = open("memleak.eml")
buffer = f.read()
f.close()
# now buffer has the email string
msg = email.message_from_string(buffer)
msg = None # this should free the memory but it doesn't
# The memory that is used in msg is not completely free
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
