[ python-Bugs-1635741 ] Interpreter seems to leak references after finalization
Bugs item #1635741, was opened at 2007-01-15 10:26
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=1635741&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: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: B Sizer (kylotan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Interpreter seems to leak references after finalization
Initial Comment:
This C code:
#include
int main(int argc, char *argv[])
{
Py_Initialize(); Py_Finalize();
Py_Initialize(); Py_Finalize();
Py_Initialize(); Py_Finalize();
Py_Initialize(); Py_Finalize();
Py_Initialize(); Py_Finalize();
Py_Initialize(); Py_Finalize();
Py_Initialize(); Py_Finalize();
}
Produces this output:
[7438 refs]
[7499 refs]
[7550 refs]
[7601 refs]
[7652 refs]
[7703 refs]
[7754 refs]
A similar program configured to call the Py_Initialize()/Py_Finalize() 1000
times ends up with:
...
[58295 refs]
[58346 refs]
[58397 refs]
This is with a fresh debug build of Python 2.5.0 on Windows XP, using Visual
C++ 2003.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1635741&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633605 ] logging module / wrong bytecode?
Bugs item #1633605, was opened at 2007-01-11 23:06
Message generated for change (Comment added) made by vsajip
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633605&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.5
>Status: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging module / wrong bytecode?
Initial Comment:
[forwarded from http://bugs.debian.org/390152]
seen with python2.4 and python2.5 on debian unstable
import logging
logging.basicConfig(level=logging.DEBUG,
format='%(pathname)s:%(lineno)d')
logging.info('whoops')
The output when the logging/__init__.pyc file exists is:
logging/__init__.py:1072
and when the __init__.pyc is deleted the output becomes:
tst.py:5
--
>Comment By: Vinay Sajip (vsajip)
Date: 2007-01-15 12:48
Message:
Logged In: YES
user_id=308438
Originator: NO
It's also possible that symlinks mean that the value stored in a .pyc file
are different to the expected values. See bug #1616422 - this appears to be
the same issue.
It's not about the frames - it's about the paths stored in the .pyc files.
If at any time the path (the module's __file__ attribute) in the .pyc file
is different to the actual path to the .py file, you would get this issue.
It's not a logging problem per se - it's that the .py path and the path in
the .pyc files don't match when they should. Logging just happens to be one
of the packages which tries to use the information.
--
Comment By: Jim Jewett (jimjjewett)
Date: 2007-01-12 21:22
Message:
Logged In: YES
user_id=764593
Originator: NO
Does debian by any chance (try to?) store the .py and .pyc files in
different directories?
The second result is correct; the second suggests that it somehow got
confused about which frames to ignore.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633605&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1635892 ] description of the beta distribution is incorrect
Bugs item #1635892, was opened at 2007-01-15 06:59 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=1635892&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: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: elgordo (azgordo) Assigned to: Nobody/Anonymous (nobody) Summary: description of the beta distribution is incorrect Initial Comment: In the random module, the documentation is incorrect. Specifically, the limits on the parameters for the beta-distribution should be changed from ">-1" to ">0". This parallels to (correct) limits on the parameters for the gamma-distribution. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1635892&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-1567331 ] logging.RotatingFileHandler has no "infinite" backupCount
Feature Requests item #1567331, was opened at 2006-09-28 21:36 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1567331&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: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Vinay Sajip (vsajip) Summary: logging.RotatingFileHandler has no "infinite" backupCount Initial Comment: It seems to me that logging.RotatingFileHandler should have a way to spell "never delete old log files". This is useful in situations where you want an external process (manual or automatic) make decisions about deleting log files. -- >Comment By: Vinay Sajip (vsajip) Date: 2007-01-15 16:44 Message: Logged In: YES user_id=308438 Originator: NO The problem with this is that on rollover, RotatingFileHandler renames old logs: rollover.log.3 -> rollover.log.4, rollover.log.2 -> rollover.log.3, rollover.log.1 -> rollover.log.2, rollover.log -> rollover.log.1, and a new rollover.log is opened. With an arbitrary number of old log files, this leads to arbitrary renaming time - which could cause long pauses due to logging, not a good idea. If you are using e.g. logrotate or newsyslog, or a custom program to do logfile rotation, you can use the new logging.handlers.WatchedFileHandler handler (meant for use on Unix/Linux only - on Windows, logfiles can't be renamed or moved while in use and so the requirement doesn't arise) which watches the logged-to file to see when it changes. This has recently been checked into SVN trunk. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1567331&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-1553380 ] Print full exceptions as they occur in logging
Feature Requests item #1553380, was opened at 2006-09-06 12:57 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1553380&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.6 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Michael Hoffman (hoffmanm) Assigned to: Vinay Sajip (vsajip) Summary: Print full exceptions as they occur in logging Initial Comment: Sometimes exceptions occur when using logging that are caused by the user code. However, logging catches these exceptions and does not give a clue as to where the error occurred. Printing full exceptions as suggested in RFE http://www.python.org/sf/1553375 would be a big help. -- >Comment By: Vinay Sajip (vsajip) Date: 2007-01-15 16:48 Message: Logged In: YES user_id=308438 Originator: NO Logging now catches very few exceptions: if logging.raiseExceptions is set to 1 (the default), exceptions are generally raised. There have been recent changes in logging to reduce the number of bare except: clauses, so I am closing this item as I believe it has been adequately addressed. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1553380&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace
Bugs item #1599254, was opened at 2006-11-19 11:03 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&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.5 Status: Open Resolution: None Priority: 9 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. -- >Comment By: A.M. Kuchling (akuchling) Date: 2007-01-15 14:01 Message: Logged In: YES user_id=11375 Originator: NO Comment from Andrew MacIntyre (os2vacpp is the OS/2 that lacks ftruncate()): I actively support the OS/2 EMX port (sys.platform == "os2emx"; build directory is PC/os2emx). I would like to keep the VAC++ port alive, but the reality is I don't have the resources to do so. The VAC++ port was the subject of discussion about removal of build support support from the source tree for 2.6 - I don't recall there being a definitive outcome, but if someone does delete the PC/os2vacpp directory, I'm not in a position to argue. AMK: (mailbox.py has a separate section of code used when file.truncate() isn't available, and the existence of this section is bedevilling me. It would be convenient if platforms without file.truncate() weren't a factor; then this branch could just be removed. In your opinion, would it hurt OS/2 users of mailbox.py if support for platforms without file.truncate() was removed?) aimacintyre: No. From what documentation I can quickly check, ftruncate() operates on file descriptors rather than FILE pointers. As such I am sure that, if it became an issue, it would not be difficult to write a ftruncate() emulation wrapper for the underlying OS/2 APIs that implement the required functionality. -- Comment By: David Watson (baikie) Date: 2007-01-13 13:32 Message: Logged In: YES user_id=1504904 Originator: YES I like the warning idea - it seems appropriate if the problem is relatively rare. How about this? File Added: mailbox-fcntl-warn.diff -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-12 14:41 Message: Logged In: YES user_id=11375 Originator: NO One OS/2 port lacks truncate(), and so does RISCOS. -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-12 13:41 Message: Logged In: YES user_id=11375 Originator: NO I realized that making flush() invalidate keys breaks the final example in the docs, which loops over inbox.iterkeys() and removes messages, doing a pack() after each message. Which platforms lack file.truncate()? Windows has it; POSIX has it, so modern Unix variants should all have it. Maybe mailbox should simply raise an exception (or trigger a warning?) if truncate is missing, and we should then assume that flush() has no effect upon keys. -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-12 12:12 Message: Logged In: YES user_id=11375 Originator: NO So shall we document flush() as invalidating keys, then? -- Comment By: David Watson (baikie) Date: 2007-01-06 14:57 Message: L
[ python-Bugs-1633628 ] time.strftime() accepts format which time.strptime doesnt
Bugs item #1633628, was opened at 2007-01-11 15:44 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633628&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.5 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: time.strftime() accepts format which time.strptime doesnt Initial Comment: [forwarded from http://bugs.debian.org/354636] time.strftime() accepts '%F %T' as format but time.strptime() doesn't, if the rule is "all what strftime accepts strptime must also" then that is bad. Check this: darwin:~# python2.4 Python 2.4.2 (#2, Nov 20 2005, 17:04:48) [GCC 4.0.3 2005 (prerelease) (Debian 4.0.2-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> format = '%F %T' >>> t = time.strftime(format) >>> t '2006-02-27 18:09:37' >>> time.strptime(t,format) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/_strptime.py", line 287, in strptime format_regex = time_re.compile(format) File "/usr/lib/python2.4/_strptime.py", line 264, in compile return re_compile(self.pattern(format), IGNORECASE) File "/usr/lib/python2.4/_strptime.py", line 256, in pattern processed_format = "%s%s%s" % (processed_format, KeyError: 'F' >>> -- >Comment By: Brett Cannon (bcannon) Date: 2007-01-15 11:15 Message: Logged In: YES user_id=357491 Originator: NO It is not a goal of strptime to support directive that are not explicitly documented as supported. time.strftime uses the platform's implementation which can implement more directives than documented. But strptime is meant to be fully platform-independent for those directive documented only. Trying to support all directives for all platforms is just a practice in futility considering how many they are and how they might be implemented differently. As both directives mentioned here are not documented as supported I am closing as invalid. -- Comment By: Mark Roberts (mark-roberts) Date: 2007-01-14 16:40 Message: Logged In: YES user_id=1591633 Originator: NO For record: %F = '%Y-%m-%d' %T = '%H:%M:%S'. Patch 1635473: http://sourceforge.net/tracker/index.php?func=detail&aid=1635473&group_id=5470&atid=305470 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633628&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1635639 ] ConfigParser does not quote %
Bugs item #1635639, was opened at 2007-01-15 01:43 Message generated for change (Comment added) made by mark-roberts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1635639&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Roberts (mark-roberts) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser does not quote % Initial Comment: This is covered by bug 1603688 (https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603688&group_id=5470) I implemented 2 versions of this patch. One version raises ValueError when an invalid interpolation syntax is encountered (such as foo%, foo%bar, and %foo, but not %%foo and %(dir)foo). The other version simply replaces appropriate %s with %%s. Initially, I believed ValueError was the appropriate way to go with this. However, when I thought about how I use ConfigParser, I realized that it would be far nicer if it simply worked. I'm +0.5 to ValueError, and +1 to munging the values. -- >Comment By: Mark Roberts (mark-roberts) Date: 2007-01-15 20:17 Message: Logged In: YES user_id=1591633 Originator: YES For the record, this was supposed to be a patch. I don't know if the admins have any way of moving it to that category. I guess that explained the funky categories and groups. Sorry for the inconvenience. -- Comment By: Mark Roberts (mark-roberts) Date: 2007-01-15 01:44 Message: Logged In: YES user_id=1591633 Originator: YES File Added: bug_1603688_cfgparser_munges.patch -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1635639&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
