[ python-Bugs-1579370 ] Segfault provoked by generators and exceptions
Bugs item #1579370, was opened at 2006-10-18 02:23 Message generated for change (Comment added) made by awaters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&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: 7 Private: No Submitted By: Mike Klaas (mklaas) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault provoked by generators and exceptions Initial Comment: A reproducible segfault when using heavily-nested generators and exceptions. Unfortunately, I haven't yet been able to provoke this behaviour with a standalone python2.5 script. There are, however, no third-party c extensions running in the process so I'm fairly confident that it is a problem in the core. The gist of the code is a series of nested generators which leave scope when an exception is raised. This exception is caught and re-raised in an outer loop. The old exception was holding on to the frame which was keeping the generators alive, and the sequence of generator destruction and new finalization caused the segfault. -- Comment By: Andrew Waters (awaters) Date: 2007-01-04 09:35 Message: Logged In: YES user_id=1418249 Originator: NO This fixes the segfault problem that I was able to reliably reproduce on Linux. We need to get this applied (assuming it is the correct fix) to the source to make Python 2.5 usable for me in production code. -- Comment By: Mike Klaas (mklaas) Date: 2006-11-27 18:41 Message: Logged In: YES user_id=1611720 Originator: YES The following patch resets the thread state of the generator when it is resumed, which prevents the segfault for me: Index: Objects/genobject.c === --- Objects/genobject.c (revision 52849) +++ Objects/genobject.c (working copy) @@ -77,6 +77,7 @@ Py_XINCREF(tstate->frame); assert(f->f_back == NULL); f->f_back = tstate->frame; +f->f_tstate = tstate; gen->gi_running = 1; result = PyEval_EvalFrameEx(f, exc); -- Comment By: Eric Noyau (eric_noyau) Date: 2006-11-27 18:07 Message: Logged In: YES user_id=1388768 Originator: NO We are experiencing the same segfault in our application, reliably. Running our unit test suite just segfault everytime on both Linux and Mac OS X. Applying Martin's patch fixes the segfault, and makes everything fine and dandy, at the cost of some memory leaks if I understand properly. This particular bug prevents us to upgrade to python 2.5 in production. -- Comment By: Tim Peters (tim_one) Date: 2006-10-28 05:18 Message: Logged In: YES user_id=31435 > I tried Tim's hope.py on Linux x86_64 and > Mac OS X 10.4 with debug builds and neither > one crashed. Tim's guess looks pretty damn > good too. Neal, note that it's the /Windows/ malloc that fills freed memory with "dangerous bytes" in a debug build -- this really has nothing to do with that it's a debug build of /Python/ apart from that on Windows a debug build of Python also links in the debug version of Microsoft's malloc. The valgrind report is pointing at the same thing. Whether this leads to a crash is purely an accident of when and how the system malloc happens to reuse the freed memory. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-28 04:56 Message: Logged In: YES user_id=33168 Mike, what platform are you having the problem on? I tried Tim's hope.py on Linux x86_64 and Mac OS X 10.4 with debug builds and neither one crashed. Tim's guess looks pretty damn good too. Here's the result of valgrind: Invalid read of size 8 at 0x4CEBFE: PyTraceBack_Here (traceback.c:117) by 0x49C1F1: PyEval_EvalFrameEx (ceval.c:2515) by 0x4F615D: gen_send_ex (genobject.c:82) by 0x4F6326: gen_close (genobject.c:128) by 0x4F645E: gen_del (genobject.c:163) by 0x4F5F00: gen_dealloc (genobject.c:31) by 0x44D207: _Py_Dealloc (object.c:1928) by 0x44534E: dict_dealloc (dictobject.c:801) by 0x44D207: _Py_Dealloc (object.c:1928) by 0x4664FF: subtype_dealloc (typeobject.c:686)
[ python-Bugs-1627690 ] documentation error for "startswith" string method
Bugs item #1627690, was opened at 2007-01-04 10: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=1627690&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: documentation error for "startswith" string method Initial Comment: At http://docs.python.org/lib/string-methods.html#l2h-241, I think prefix can also be a tuple of suffixes to look for. should be prefix can also be a tuple of prefixes to look for. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627690&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1579370 ] Segfault provoked by generators and exceptions
Bugs item #1579370, was opened at 2006-10-18 04:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&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: 7 Private: No Submitted By: Mike Klaas (mklaas) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault provoked by generators and exceptions Initial Comment: A reproducible segfault when using heavily-nested generators and exceptions. Unfortunately, I haven't yet been able to provoke this behaviour with a standalone python2.5 script. There are, however, no third-party c extensions running in the process so I'm fairly confident that it is a problem in the core. The gist of the code is a series of nested generators which leave scope when an exception is raised. This exception is caught and re-raised in an outer loop. The old exception was holding on to the frame which was keeping the generators alive, and the sequence of generator destruction and new finalization caused the segfault. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-01-04 11:42 Message: Logged In: YES user_id=21627 Originator: NO Why do frame objects have a thread state in the first place? In particular, why does PyTraceBack_Here get the thread state from the frame, instead of using the current thread? Introduction of f_tstate goes back to r7882, but it is not clear why it was done that way. -- Comment By: Andrew Waters (awaters) Date: 2007-01-04 10:35 Message: Logged In: YES user_id=1418249 Originator: NO This fixes the segfault problem that I was able to reliably reproduce on Linux. We need to get this applied (assuming it is the correct fix) to the source to make Python 2.5 usable for me in production code. -- Comment By: Mike Klaas (mklaas) Date: 2006-11-27 19:41 Message: Logged In: YES user_id=1611720 Originator: YES The following patch resets the thread state of the generator when it is resumed, which prevents the segfault for me: Index: Objects/genobject.c === --- Objects/genobject.c (revision 52849) +++ Objects/genobject.c (working copy) @@ -77,6 +77,7 @@ Py_XINCREF(tstate->frame); assert(f->f_back == NULL); f->f_back = tstate->frame; +f->f_tstate = tstate; gen->gi_running = 1; result = PyEval_EvalFrameEx(f, exc); -- Comment By: Eric Noyau (eric_noyau) Date: 2006-11-27 19:07 Message: Logged In: YES user_id=1388768 Originator: NO We are experiencing the same segfault in our application, reliably. Running our unit test suite just segfault everytime on both Linux and Mac OS X. Applying Martin's patch fixes the segfault, and makes everything fine and dandy, at the cost of some memory leaks if I understand properly. This particular bug prevents us to upgrade to python 2.5 in production. -- Comment By: Tim Peters (tim_one) Date: 2006-10-28 07:18 Message: Logged In: YES user_id=31435 > I tried Tim's hope.py on Linux x86_64 and > Mac OS X 10.4 with debug builds and neither > one crashed. Tim's guess looks pretty damn > good too. Neal, note that it's the /Windows/ malloc that fills freed memory with "dangerous bytes" in a debug build -- this really has nothing to do with that it's a debug build of /Python/ apart from that on Windows a debug build of Python also links in the debug version of Microsoft's malloc. The valgrind report is pointing at the same thing. Whether this leads to a crash is purely an accident of when and how the system malloc happens to reuse the freed memory. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-28 06:56 Message: Logged In: YES user_id=33168 Mike, what platform are you having the problem on? I tried Tim's hope.py on Linux x86_64 and Mac OS X 10.4 with debug builds and neither one crashed. Tim's guess looks pretty damn good too. Here's the result of valgrind: Invalid read of size 8 at 0x4CEBFE: PyTraceBack_Here (traceback.c:117) by 0x49C1F1: PyEval_EvalFrameEx (ceval.c:2515) by 0x4F615D: gen_send_ex (genobject.c:82) by 0x4F6326: gen_close (genobject.c:128) by 0x4F645E
[ python-Bugs-1627096 ] xml.dom.minidom parse bug
Bugs item #1627096, was opened at 2007-01-03 17:06
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627096&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: Invalid
Priority: 5
Private: No
Submitted By: Pierre Imbaud (pmi)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.dom.minidom parse bug
Initial Comment:
xml.dom.minidom was unable to parse an xml file that came from an example
provided by an official organism.(http://www.iptc.org/IPTC4XMP)
The parsed file was somewhat hairy, but I have been able to reproduce the bug
with a simplified
version, attached. (ends with .xmp: its supposed
to be an xmp file, the xmp standard being built on
xml. Well, thats the short story).
The offending part is the one that goes: xmpPLUS=''
it triggers an exception: ValueError: too many values to unpack,
in _parse_ns_name. Some debugging showed an obvious mistake
in the scanning of the name argument, that goes beyond the closing
" ' ".
I digged a little further thru a pdb session, but the bug seems to be located
in c code.
Thats the very first time I report a bug, chances are I provide too much or too
little information...
To whoever it may concern, here is the invoking code:
from xml.dom import minidom
...
class xmp(dict):
def __init__(self, inStream):
xmldoc = minidom.parse(inStream)
x = xmp('/home/pierre/devt/port/IPTCCore-Full/x.xmp')
traceback:
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/xmpLib.py in
__init__(self, inStream)
26 def __init__(self, inStream):
27 print minidom
---> 28 xmldoc = minidom.parse(inStream)
29 xmpmeta = xmldoc.childNodes[1]
30 rdf = xmpmeta.childNodes[1]
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/nxml/dom/minidom.py in
parse(file, parser, bufsize)
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/xml/dom/expatbuilder.py
in parse(file, namespaces)
922 fp = open(file, 'rb')
923 try:
--> 924 result = builder.parseFile(fp)
925 finally:
926 fp.close()
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/xml/dom/expatbuilder.py
in parseFile(self, file)
205 if not buffer:
206 break
--> 207 parser.Parse(buffer, 0)
208 if first_buffer and self.document.documentElement:
209 self._setup_subset(buffer)
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/xml/dom/expatbuilder.py
in start_element_handler(self, name, attributes)
743 def start_element_handler(self, name, attributes):
744 if ' ' in name:
--> 745 uri, localname, prefix, qname = _parse_ns_name(self, name)
746 else:
747 uri = EMPTY_NAMESPACE
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/xml/dom/expatbuilder.py
in _parse_ns_name(builder, name)
125 localname = intern(localname, localname)
126 else:
--> 127 uri, localname = parts
128 prefix = EMPTY_PREFIX
129 qname = localname = intern(localname, localname)
ValueError: too many values to unpack
The offending c statement:
/usr/src/packages/BUILD/Python-2.4/Modules/pyexpat.c(582)StartElement()
The returned 'name':
(Pdb) name
Out[5]: u'XMP Photographic Licensing Universal System (xmpPLUS,
http://ns.adobe.com/xap/1.0/PLUS/) CreditLineReq xmpPLUS'
Its obvious the scanning went beyond the attribute.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-01-04 12:18
Message:
Logged In: YES
user_id=21627
Originator: NO
This is not a bug in Python, but a bug in the XML document. According to
section 2.1 of
http://www.w3.org/TR/2006/REC-xml-names-20060816/
an XML namespace must be an URI reference; according to RFC 3986, the
string "XMP Photographic Licensing Universal System (xmpPLUS,
http://ns.adobe.com/xap/1.0/PLUS/)" is not an URI reference, as it
contains spaces.
Closing this report as invalid.
If you want to work around this bug, you can parse the file in
non-namespace mode, using
xml.dom.expatbuilder.parse("/tmp/x.xmp", namespaces=False)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627096&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1627952 ] plat-mac videoreader.py auido format info
Bugs item #1627952, was opened at 2007-01-04 09:18 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=1627952&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: 5 Private: No Submitted By: Ryan Owen (ryaowe) Assigned to: Nobody/Anonymous (nobody) Summary: plat-mac videoreader.py auido format info Initial Comment: videoreader.py in the plat-mac modules has a small bug that breaks reader.GetAudioFormat() --- videoreader.py Thu Jan 04 09:05:16 2007 +++ videoreader_fixed.pyThu Jan 04 09:05:11 2007 @@ -13,7 +13,7 @@ from Carbon import Qdoffs from Carbon import QDOffscreen from Carbon import Res try: -import MediaDescr +from Carbon import MediaDescr except ImportError: def _audiodescr(data): return None -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627952&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1627956 ] documentation error for "startswith" string method
Bugs item #1627956, was opened at 2007-01-04 16:21 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=1627956&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: documentation error for "startswith" string method Initial Comment: At http://docs.python.org/lib/string-methods.html#l2h-241, I think prefix can also be a tuple of suffixes to look for. should be prefix can also be a tuple of prefixes to look for. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627956&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1598181 ] subprocess.py: O(N**2) bottleneck
Bugs item #1598181, was opened at 2006-11-16 22:40 Message generated for change (Comment added) made by mklaas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598181&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: 5 Private: No Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Peter Åstrand (astrand) Summary: subprocess.py: O(N**2) bottleneck Initial Comment: subprocess.py (Python 2.5, current SVN, probably all versions) contains this O(N**2) code: bytes_written = os.write(self.stdin.fileno(), input[:512]) input = input[bytes_written:] For large but reasonable "input" the second line is rate limiting. Luckily, it is very easy to remove this bottleneck. I'll upload a simple patch. Below is a small script that demonstrates the huge speed difference. The output on my machine is: creating input 0.888417959213 slow slicing input 61.1553330421 creating input 0.863168954849 fast slicing input 0.0163860321045 done The numbers are times in seconds. This is the source: import time import sys size = 100 t0 = time.time() print "creating input" input = "\n".join([str(i) for i in xrange(size)]) print time.time()-t0 t0 = time.time() print "slow slicing input" n_out_slow = 0 while True: out = input[:512] n_out_slow += 1 input = input[512:] if not input: break print time.time()-t0 t0 = time.time() print "creating input" input = "\n".join([str(i) for i in xrange(size)]) print time.time()-t0 t0 = time.time() print "fast slicing input" n_out_fast = 0 input_done = 0 while True: out = input[input_done:input_done+512] n_out_fast += 1 input_done += 512 if input_done >= len(input): break print time.time()-t0 assert n_out_fast == n_out_slow print "done" -- Comment By: Mike Klaas (mklaas) Date: 2007-01-04 10:20 Message: Logged In: YES user_id=1611720 Originator: NO I reviewed the patch--the proposed fix looks good. Minor comments: - "input_done" sounds like a flag, not a count of written bytes - buffer() could be used to avoid the 512-byte copy created by the slice -- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2006-11-16 22:43 Message: Logged In: YES user_id=71407 Originator: YES Sorry, I didn't know the tracker would destroy the indentation. I'm uploading the demo source as a separate file. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598181&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1566280 ] Logging problem on Windows XP
Bugs item #1566280, was opened at 2006-09-27 13:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&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: None >Status: Closed >Resolution: Fixed Priority: 7 Private: No Submitted By: Pavel Krupets (pavel_krupets) Assigned to: Martin v. Löwis (loewis) Summary: Logging problem on Windows XP Initial Comment: Traceback (most recent call last): File "C:\Python\Lib\logging\handlers.py", line 73, in emit if self.shouldRollover(record): File "C:\Python\Lib\logging\handlers.py", line 147, in shouldRollover self.stream.seek(0, 2) #due to non-posix-compliant Windows feature ValueError: I/O operation on closed file not sure why this file is closed. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-01-04 22:08 Message: Logged In: YES user_id=21627 Originator: NO Thanks again for the report. This is now fixed in r53249 and r53250. -- Comment By: Martin v. Löwis (loewis) Date: 2006-12-18 18:26 Message: Logged In: YES user_id=21627 Originator: NO I cannot reproduce the crash with the example given, neither with the released binaries, nor with any of the trunk or release25-maint subversion branches. Therefore, I declare that this report is only about the ValueError; if anybody has a way to provoke a crash in a reproducable way, please submit it as a separate report, along with precise instructions on how to provoke the crash. -- Comment By: Martin v. Löwis (loewis) Date: 2006-12-06 19:58 Message: Logged In: YES user_id=21627 Originator: NO eloff: It may be that there are different problems that all show the symptom; *this* problem reported here can only occur if you are using multiple threads (atleast for the ValueError; haven't looked into the crash at all). Yes, you can run multiple threads, and yes, you can use logging freely. However, you should not let the main thread just "run off". Instead, you should end your main thread with an explicit .join() operation on all threads it has created; those threads themselves should perform explicit .join() operations on all threads they create. That way, you can guarantee orderly shutdown. threading.py tries to do the joining if you don't, but fails (and the approach it uses is inherently error-prone). -- Comment By: Daniel Eloff (eloff) Date: 2006-12-06 19:43 Message: Logged In: YES user_id=730918 Originator: NO Thanks Martin, I applied the patch. The problem I was having was the IO Error, sorry for being vague. The part I don't understand is I should not have had other threads running (and definately should not have had the logger being used outside the main thread.) Can the problem occur with just one thread? I was running under the debugger in wing, I don't know if that might cause this problem. Anyway if I find out anything else I'll let you know. If you don't hear from me then everything is working great. -- Comment By: Mike Powers (mikepowers48) Date: 2006-12-06 16:22 Message: Logged In: YES user_id=1614975 Originator: NO I'm seeing the I/O error and crash a lot on Windows and the I/O error on Linux. Any help would be greatly appreciated. -- Comment By: Martin v. Löwis (loewis) Date: 2006-12-06 08:29 Message: Logged In: YES user_id=21627 Originator: NO Ok, so tsample.zip is a test case for the original problem, right? I can reproduce the problem on Linux also. I can't make it crash (on Linux); what do have to do to make it crash? If I access localhost:8080, I get log messages saying 2006-12-06 07:21:06,999 INFO servlet::__init__:1091 code 404, message File not found eloff: this report actually reports two problems (the I/O error, and the crash). Which of these are you having and have found lots of people having? As for the traceback problem: this is due to the main thread terminating, and therefore the logging atexit handler getting invoked, which closes the file. Only then is the threading atexit handler invoked, which waits until all non-daemon threads terminate. As a work-around, add httpServer.join() at the end of your script. I'll attach a patch that fixes this problem in the Python library. File Added: threading.diff -- Comment By: Daniel Eloff (eloff) Date: 2006-12-06 04:05 Message: Logged In: YES user_id=730918 Originator: NO I have this
[ python-Bugs-1627690 ] documentation error for "startswith" string method
Bugs item #1627690, was opened at 2007-01-04 11:06 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627690&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.5 >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: documentation error for "startswith" string method Initial Comment: At http://docs.python.org/lib/string-methods.html#l2h-241, I think prefix can also be a tuple of suffixes to look for. should be prefix can also be a tuple of prefixes to look for. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-01-04 22:09 Message: Logged In: YES user_id=21627 Originator: NO This is a duplicate of 1627956. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627690&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1626801 ] posixmodule.c leaks crypto context on Windows
Bugs item #1626801, was opened at 2007-01-03 11:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1626801&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: Extension Modules Group: Python 2.6 Status: Open Resolution: None >Priority: 5 Private: No Submitted By: Yitz Gale (ygale) Assigned to: Martin v. Löwis (loewis) Summary: posixmodule.c leaks crypto context on Windows Initial Comment: The Win API docs for CryptAcquireContext require that the context be released after use by calling CryptReleaseContext, but posixmodule.c fails to do so in win32_urandom(). -- >Comment By: Martin v. Löwis (loewis) Date: 2007-01-04 22:13 Message: Logged In: YES user_id=21627 Originator: NO I fail to see the problem. Only a single crypto context is allocated, and it is used all the time, i.e. until the Python interpreter finishes, at which time it is automatically released by the operating system. -- Comment By: Yitz Gale (ygale) Date: 2007-01-03 13:12 Message: Logged In: YES user_id=1033539 Originator: YES You might consider backporting this to 2.5 and 2.4. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1626801&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1626801 ] posixmodule.c leaks crypto context on Windows
Bugs item #1626801, was opened at 2007-01-03 12:47 Message generated for change (Comment added) made by ygale You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1626801&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: Extension Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Yitz Gale (ygale) Assigned to: Martin v. Löwis (loewis) Summary: posixmodule.c leaks crypto context on Windows Initial Comment: The Win API docs for CryptAcquireContext require that the context be released after use by calling CryptReleaseContext, but posixmodule.c fails to do so in win32_urandom(). -- >Comment By: Yitz Gale (ygale) Date: 2007-01-04 23:46 Message: Logged In: YES user_id=1033539 Originator: YES How do you know that "it is automatically released by the operating system?" The documentation for CryptAcquireContext states: "When you have finished using the CSP, release the handle by calling the CryptReleaseContext function." In the example code provided, the wording in the comments is even stronger: "When the handle is no longer needed, it must be released." The example code then explicitly calls CryptReleaseContext. Do you know absolutely for certain that we are not leaking resourses if we violate this clear API requirement? Reference: http://msdn2.microsoft.com/en-us/library/aa379886.aspx -- Comment By: Martin v. Löwis (loewis) Date: 2007-01-04 23:13 Message: Logged In: YES user_id=21627 Originator: NO I fail to see the problem. Only a single crypto context is allocated, and it is used all the time, i.e. until the Python interpreter finishes, at which time it is automatically released by the operating system. -- Comment By: Yitz Gale (ygale) Date: 2007-01-03 14:12 Message: Logged In: YES user_id=1033539 Originator: YES You might consider backporting this to 2.5 and 2.4. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1626801&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1626801 ] posixmodule.c leaks crypto context on Windows
Bugs item #1626801, was opened at 2007-01-03 11:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1626801&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: Extension Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Yitz Gale (ygale) Assigned to: Martin v. Löwis (loewis) Summary: posixmodule.c leaks crypto context on Windows Initial Comment: The Win API docs for CryptAcquireContext require that the context be released after use by calling CryptReleaseContext, but posixmodule.c fails to do so in win32_urandom(). -- >Comment By: Martin v. Löwis (loewis) Date: 2007-01-05 01:46 Message: Logged In: YES user_id=21627 Originator: NO Yes, I'm absolutely certain that terminating a process releases all handles, on Windows NT+. -- Comment By: Yitz Gale (ygale) Date: 2007-01-04 22:46 Message: Logged In: YES user_id=1033539 Originator: YES How do you know that "it is automatically released by the operating system?" The documentation for CryptAcquireContext states: "When you have finished using the CSP, release the handle by calling the CryptReleaseContext function." In the example code provided, the wording in the comments is even stronger: "When the handle is no longer needed, it must be released." The example code then explicitly calls CryptReleaseContext. Do you know absolutely for certain that we are not leaking resourses if we violate this clear API requirement? Reference: http://msdn2.microsoft.com/en-us/library/aa379886.aspx -- Comment By: Martin v. Löwis (loewis) Date: 2007-01-04 22:13 Message: Logged In: YES user_id=21627 Originator: NO I fail to see the problem. Only a single crypto context is allocated, and it is used all the time, i.e. until the Python interpreter finishes, at which time it is automatically released by the operating system. -- Comment By: Yitz Gale (ygale) Date: 2007-01-03 13:12 Message: Logged In: YES user_id=1033539 Originator: YES You might consider backporting this to 2.5 and 2.4. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1626801&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
