[ python-Bugs-1112856 ] patch 1079734 broke cgi.FieldStorage w/ multipart post req.
Bugs item #1112856, was opened at 2005-01-31 00:58
Message generated for change (Comment added) made by arigo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&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: Fixed
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch 1079734 broke cgi.FieldStorage w/ multipart post req.
Initial Comment:
Patch 1079734 "Make cgi.py use email instead of rfc822
or mimetools" seems to have broken the cgi.FieldStorage
in cases where the request is a multipart post (for
instance, when a file upload form field is used).
See the attached test program.
With cgi.py revision <1.83 (python 2.4 for instance) I
get the expected results;
374
FieldStorage(None, None, [FieldStorage('param1', None,
'Value of param1'), FieldStorage('param2', None, 'Value
of param2'), FieldStorage('file', '', ''),
FieldStorage(None, None, '')])
but with cgi.py rev 1.83 (current) I get this:
374
FieldStorage(None, None, [FieldStorage('param1', None,
'')])
Another thing that I observed (which isn't reproduced
by this test program) is that cgi.FieldStorage.__init__
never completes when the fp is a socket-file (and the
request is again a multipart post). It worked fine with
the old cgi.py.
--
>Comment By: Armin Rigo (arigo)
Date: 2005-09-19 09:12
Message:
Logged In: YES
user_id=4771
Reverted (Lib/cgi.py r1.85).
--
Comment By: Josh Hoyt (joshhoyt)
Date: 2005-09-16 15:58
Message:
Logged In: YES
user_id=693077
Yes, please revert the patch.
--
Comment By: Irmen de Jong (irmen)
Date: 2005-09-16 13:40
Message:
Logged In: YES
user_id=129426
I vote for revert, so that my code may run again on Python 2.5.
Also see Josh's comment , with which I agree.
--
Comment By: Armin Rigo (arigo)
Date: 2005-09-16 11:52
Message:
Logged In: YES
user_id=4771
The problem is still there now (5 months later), so should I go ahead and
revert the cgi.py changes of r1.83? I does break user code out there.
--
Comment By: Josh Hoyt (joshhoyt)
Date: 2005-04-17 23:39
Message:
Logged In: YES
user_id=693077
I've been playing with using the email parser to do the
whole job of parsing the data, and I think it's too big of a
change. It'd be very hard to ensure API compatibility and
the same behaviour. I think that in the long run, it's the
right thing to do, but I think that the API should change
when that change is made. My recommendation for the time
being is to revert the original patch that I made.
--
Comment By: Irmen de Jong (irmen)
Date: 2005-02-08 21:40
Message:
Logged In: YES
user_id=129426
I've added a test that shows the 'freezing' problem I talked
about.
Start the server.py, it will listen on port 9000. Open the
post.html in your web browser, enter some form data, and
submit the form.
It will POST to the server.py and if you started that one
with cvs-python (2.5a0) it will freeze on the marked line.
If you start server.py with Python 2.4, it will work fine.
--
Comment By: Irmen de Jong (irmen)
Date: 2005-02-06 22:58
Message:
Logged In: YES
user_id=129426
Yes, I'll try to make a test case for that within the next
few days.
--
Comment By: Josh Hoyt (joshhoyt)
Date: 2005-02-04 23:02
Message:
Logged In: YES
user_id=693077
Irmen, can you try to create a test case where the
cgi.FieldStorage never completes, so I can make sure that
any fix I come up with resolves it?
I will try to put together an implementation where the email
parser parses the whole multipart message.
--
Comment By: Irmen de Jong (irmen)
Date: 2005-02-04 22:06
Message:
Logged In: YES
user_id=129426
Johannes: while your patch makes my cgibug.py test case run
fine, it has 2 problems:
1- it runs much slower than the python2.4 code (probably
because of the reading back thing Josh is talking about);
2- it still doesn't fix the second problem that I observed:
cgi.FieldStorage never completes when fp is a socket. I
don't have a separate test case for this yet, sorry.
So Josh: perhaps your idea doesn't have these 2 problems?
--
Comment By: Josh Hoyt (joshhoyt)
Date:
[ python-Bugs-1295179 ] termios.c in qnx4.25
Bugs item #1295179, was opened at 2005-09-19 17:28 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=1295179&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: Open Resolution: None Priority: 5 Submitted By: kbob_ru (kbob_ru) Assigned to: Nobody/Anonymous (nobody) Summary: termios.c in qnx4.25 Initial Comment: I compile python version 2.3.5 in QNX4.25. But I found that #include don't work because in qnx4 we need to include first in which #include already present. Second, Module/termios.c needs flag IXANY, that not defined in qnx4 headers. Include right header and write #ifdef IXANY \ #endif around helps to compile Module/termios.c. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295179&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1199282 ] subprocess _active.remove(self) self not in list _active
Bugs item #1199282, was opened at 2005-05-10 18:24
Message generated for change (Comment added) made by atila-cheops
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&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: cheops (atila-cheops)
Assigned to: Peter Åstrand (astrand)
Summary: subprocess _active.remove(self) self not in list _active
Initial Comment:
I start a subprocess in a seperate thread (25 concurrent
threads)
in some of the threads the following error occurs
Exception in thread Thread-4:
Traceback (most recent call last):
File "C:\Python24\lib\threading.py", line 442, in
__bootstrap
self.run()
File "upgrade.py", line 45, in run
returncode = p.wait()
File "C:\Python24\lib\subprocess.py", line 765, in wait
_active.remove(self)
ValueError: list.remove(x): x not in list
this is the code that starts the subprocess and where I
wait for the result
p = subprocess.Popen('command', stdin=None,
stdout=subprocess.PIPE, stderr=subprocess.STDOUT,
universal_newlines=True)
returncode = p.wait()
errormessage = p.stdout.readlines()
--
>Comment By: cheops (atila-cheops)
Date: 2005-09-19 09:29
Message:
Logged In: YES
user_id=1276121
I noticed this bug under windows
to reproduce the bug, I attached the script I use, but this
needs input, I tried with a simpler example (pinging a number
of host concurrently) but that did not cause the bug.
--
Comment By: Peter Åstrand (astrand)
Date: 2005-06-23 16:03
Message:
Logged In: YES
user_id=344921
I believe it should be sufficient to add a try...except
clause around _active.remove(). Can you upload a complete
example that triggers the bug? Have you noticed this bug on
Windows, UNIX or both platforms?
--
Comment By: cheops (atila-cheops)
Date: 2005-05-12 10:17
Message:
Logged In: YES
user_id=1276121
this might be related to bug 1183780
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1284928 ] logging module's setLoggerClass not really working
Bugs item #1284928, was opened at 2005-09-08 13:51 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284928&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: Open Resolution: None Priority: 5 Submitted By: Rotem Yaari (rotem_ya) Assigned to: Nobody/Anonymous (nobody) Summary: logging module's setLoggerClass not really working Initial Comment: The logging package should be modified in a way which would let users call the setLoggerClass API, and then consistently get loggers only from that class. In the logging package as it is today, the root logger will always be a logging.Logger instance, and not the new class specified in the call to setLoggerClass. These semantics are not clear. -- >Comment By: Vinay Sajip (vsajip) Date: 2005-09-19 12:31 Message: Logged In: YES user_id=308438 OK - I'm part way through implementing a change whereby the function name is available through the base logging functionality - the findCaller() implementation in CVS currently gets the function name, but I have not yet implemented the part which puts it into the LogRecord. So this particular patch of yours will soon not be necessary. Also note that you can also redefine the record-making function - but I am currently thinking of how to make this part of the system better, as it is a little untidy at the moment. The objective is to make it easy to add whatever you want to the LogRecord __dict__ which can later be used in the formatted output. -- Comment By: Rotem Yaari (rotem_ya) Date: 2005-09-19 06:34 Message: Logged In: YES user_id=1340892 This is an example logger class I would like to use: class PatchedLogger(logging.Logger): def __init__(self, name, *patches): logging.Logger.__init__(self, name) self.patches = patches def handle(self, record): #copied from the actual Logger implementation if (not self.disabled) and self.filter(record): for patch in self.patches: patch(record) self.callHandlers(record) And an example "patch": def EnableTrace(record): """ adds the %(function)s for logging records """ function_name = _get_function_name(inspect.stack()[4]) record.function = function_name -- Comment By: Vinay Sajip (vsajip) Date: 2005-09-19 01:00 Message: Logged In: YES user_id=308438 Can you please explain your use case? Why does the package have to be modified in that way? Why do you need to be able to have the root logger be creatable from a custom class? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284928&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1284928 ] logging module's setLoggerClass not really working
Bugs item #1284928, was opened at 2005-09-08 16:51 Message generated for change (Comment added) made by rotem_ya You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284928&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: Open Resolution: None Priority: 5 Submitted By: Rotem Yaari (rotem_ya) Assigned to: Nobody/Anonymous (nobody) Summary: logging module's setLoggerClass not really working Initial Comment: The logging package should be modified in a way which would let users call the setLoggerClass API, and then consistently get loggers only from that class. In the logging package as it is today, the root logger will always be a logging.Logger instance, and not the new class specified in the call to setLoggerClass. These semantics are not clear. -- >Comment By: Rotem Yaari (rotem_ya) Date: 2005-09-19 16:15 Message: Logged In: YES user_id=1340892 That sounds fine. The only thing I think is important is that it'll be possible to add fields to the LogRecord in the period of time between its creation and its "emitting". That will let users add any behavior desired to the logging mechanism. In addition, since setLoggerClass is obviously not intended for users, it should be prefixed with an underscore or made "pseudo private"... its otherwise confusing. -- Comment By: Vinay Sajip (vsajip) Date: 2005-09-19 15:31 Message: Logged In: YES user_id=308438 OK - I'm part way through implementing a change whereby the function name is available through the base logging functionality - the findCaller() implementation in CVS currently gets the function name, but I have not yet implemented the part which puts it into the LogRecord. So this particular patch of yours will soon not be necessary. Also note that you can also redefine the record-making function - but I am currently thinking of how to make this part of the system better, as it is a little untidy at the moment. The objective is to make it easy to add whatever you want to the LogRecord __dict__ which can later be used in the formatted output. -- Comment By: Rotem Yaari (rotem_ya) Date: 2005-09-19 09:34 Message: Logged In: YES user_id=1340892 This is an example logger class I would like to use: class PatchedLogger(logging.Logger): def __init__(self, name, *patches): logging.Logger.__init__(self, name) self.patches = patches def handle(self, record): #copied from the actual Logger implementation if (not self.disabled) and self.filter(record): for patch in self.patches: patch(record) self.callHandlers(record) And an example "patch": def EnableTrace(record): """ adds the %(function)s for logging records """ function_name = _get_function_name(inspect.stack()[4]) record.function = function_name -- Comment By: Vinay Sajip (vsajip) Date: 2005-09-19 04:00 Message: Logged In: YES user_id=308438 Can you please explain your use case? Why does the package have to be modified in that way? Why do you need to be able to have the root logger be creatable from a custom class? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284928&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1295432 ] cookielib undefined local variable error
Bugs item #1295432, was opened at 2005-09-19 09:42 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=1295432&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: Yusuke Shinyama (euske) Assigned to: Nobody/Anonymous (nobody) Summary: cookielib undefined local variable error Initial Comment: The domain_return_ok() method in DefaultCookiePolicy class got Undefined local variable exception with cookies returned by some websites. I couldn't see the cookie which caused the problem. But it seems this is because the local variables dotted_req_host and dotted_erhn are first assigned in a if statement and might not be always defined. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295432&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1295432 ] cookielib undefined local variable error
Bugs item #1295432, was opened at 2005-09-19 15:42 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295432&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: Out of Date Priority: 5 Submitted By: Yusuke Shinyama (euske) Assigned to: Nobody/Anonymous (nobody) Summary: cookielib undefined local variable error Initial Comment: The domain_return_ok() method in DefaultCookiePolicy class got Undefined local variable exception with cookies returned by some websites. I couldn't see the cookie which caused the problem. But it seems this is because the local variables dotted_req_host and dotted_erhn are first assigned in a if statement and might not be always defined. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-19 20:50 Message: Logged In: YES user_id=1188172 This was already fixed with patch #1116583 on 2005/02/05. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295432&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1295179 ] termios.c in qnx4.25
Bugs item #1295179, was opened at 2005-09-19 11:28 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295179&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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: kbob_ru (kbob_ru) Assigned to: Nobody/Anonymous (nobody) Summary: termios.c in qnx4.25 Initial Comment: I compile python version 2.3.5 in QNX4.25. But I found that #include don't work because in qnx4 we need to include first in which #include already present. Second, Module/termios.c needs flag IXANY, that not defined in qnx4 headers. Include right header and write #ifdef IXANY \ #endif around helps to compile Module/termios.c. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295179&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1295808 ] expat symbols should be namespaced in pyexpat
Bugs item #1295808, was opened at 2005-09-19 21:44 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=1295808&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Trent Mick (tmick) Assigned to: Nobody/Anonymous (nobody) Summary: expat symbols should be namespaced in pyexpat Initial Comment: The Problem: - you embed Python in some app - the app dynamically loads libexpat of version X - the embedded Python imports pyexpat (which was built against libexpat version X+n) --> pyexpat gets the expat symbols from the already loaded and *older* libexpat: crash (Specifically the crash we observed was in getting an old XML_ErrorString (from xmlparse.c) and then calling it with newer values in the XML_Error enum: // pyexpat.c, line 1970 ... // Added in Expat 1.95.7. MYCONST(XML_ERROR_UNBOUND_PREFIX); ... The Solution: Prefix all a exported symbols with "PyExpat_". This is similar to what Mozilla does for some common libs: http://lxr.mozilla.org/seamonkey/source/modules/libimg/png/mozpngconf.h#115 I'll attach the gdb backtrace that we were getting and a patch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295808&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1093389 ] mapitags.PROP_TAG() doesn't account for new longs
Bugs item #1093389, was opened at 2004-12-30 11:36 Message generated for change (Comment added) made by hildjj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093389&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: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Joe Hildebrand (hildjj) Assigned to: Mark Hammond (mhammond) Summary: mapitags.PROP_TAG() doesn't account for new longs Initial Comment: Test case: >>> from win32com.mapi.mapitags import * >>> PROP_TAG(PT_LONG, 0x8041) 2151743491L Should be: -2143223805L or, alternately, the rest of the mapi interfaces should know about unsigned ints. -- >Comment By: Joe Hildebrand (hildjj) Date: 2005-09-19 17:43 Message: Logged In: YES user_id=101697 For example, you could use this (awful hack): def PROP_TAG(ulPropType,ulPropID): a = (ulPropID<<16)|(ulPropType) if ulPropID & 0x8000: a = int(-((a ^ 0x) + 1)) return a mostly posted here so i can google for it next time... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093389&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1295909 ] inspect.getsource() misses single line blocks.
Bugs item #1295909, was opened at 2005-09-19 21:00
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=1295909&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: Ron Adam (ronadam)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.getsource() misses single line blocks.
Initial Comment:
While playing around with the inspect module I found
that the Blockfinder doesn't recognize single line
function definitions.
Adding the following two lines to it fixes it, but I'm
not sure if it causes problems anywhere else.
C:\Python24\Lib>diff.py inspect.py inspect_.py
*** inspect.py Tue Mar 15 13:22:02 2005
--- inspect_.py Mon Sep 19 14:26:26 2005
***
*** 531,536
--- 531,538
raise EndOfBlock, self.last
elif type == tokenize.NAME and scol == 0:
raise EndOfBlock, self.last
+ elif self.indent == 0:
+ raise EndOfBlock, self.last
def getblock(lines):
"""Extract the block of code at the top of the
given list of lines."""
Version info:
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310
32 bit (Intel)] on win32
def test(t):
print '**',t,'**'
print "Line:"
def f(): pass
""" This line shouldn't be visible """
print inspect.getsource(f)
print "Block:"
def f():
pass
pass
"""This line should not be visible."""
print inspect.getsource(f)
import inspect
test("before")
import inspect_ as inspect
test("after")
#-- output --
** before **
Line:
def f(): pass
""" This line shouldn't be visible """
print inspect.getsource(f)
print "Block:"
def f():
pass
pass
Block:
def f():
pass
pass
** after **
Line:
def f(): pass
Block:
def f():
pass
pass
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295909&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1112856 ] patch 1079734 broke cgi.FieldStorage w/ multipart post req.
Bugs item #1112856, was opened at 2005-01-31 11:58
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&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: Fixed
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch 1079734 broke cgi.FieldStorage w/ multipart post req.
Initial Comment:
Patch 1079734 "Make cgi.py use email instead of rfc822
or mimetools" seems to have broken the cgi.FieldStorage
in cases where the request is a multipart post (for
instance, when a file upload form field is used).
See the attached test program.
With cgi.py revision <1.83 (python 2.4 for instance) I
get the expected results;
374
FieldStorage(None, None, [FieldStorage('param1', None,
'Value of param1'), FieldStorage('param2', None, 'Value
of param2'), FieldStorage('file', '', ''),
FieldStorage(None, None, '')])
but with cgi.py rev 1.83 (current) I get this:
374
FieldStorage(None, None, [FieldStorage('param1', None,
'')])
Another thing that I observed (which isn't reproduced
by this test program) is that cgi.FieldStorage.__init__
never completes when the fp is a socket-file (and the
request is again a multipart post). It worked fine with
the old cgi.py.
--
>Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-09-20 13:18
Message:
Logged In: YES
user_id=29957
Er - while reverting it makes the code work again, I'm
_really_ unhappy with this as a long-term solution. We
really need to be getting rid of the old, unmaintained, and
generally awful code of things like mimetools.
--
Comment By: Armin Rigo (arigo)
Date: 2005-09-19 19:12
Message:
Logged In: YES
user_id=4771
Reverted (Lib/cgi.py r1.85).
--
Comment By: Josh Hoyt (joshhoyt)
Date: 2005-09-17 01:58
Message:
Logged In: YES
user_id=693077
Yes, please revert the patch.
--
Comment By: Irmen de Jong (irmen)
Date: 2005-09-16 23:40
Message:
Logged In: YES
user_id=129426
I vote for revert, so that my code may run again on Python 2.5.
Also see Josh's comment , with which I agree.
--
Comment By: Armin Rigo (arigo)
Date: 2005-09-16 21:52
Message:
Logged In: YES
user_id=4771
The problem is still there now (5 months later), so should I go ahead and
revert the cgi.py changes of r1.83? I does break user code out there.
--
Comment By: Josh Hoyt (joshhoyt)
Date: 2005-04-18 09:39
Message:
Logged In: YES
user_id=693077
I've been playing with using the email parser to do the
whole job of parsing the data, and I think it's too big of a
change. It'd be very hard to ensure API compatibility and
the same behaviour. I think that in the long run, it's the
right thing to do, but I think that the API should change
when that change is made. My recommendation for the time
being is to revert the original patch that I made.
--
Comment By: Irmen de Jong (irmen)
Date: 2005-02-09 08:40
Message:
Logged In: YES
user_id=129426
I've added a test that shows the 'freezing' problem I talked
about.
Start the server.py, it will listen on port 9000. Open the
post.html in your web browser, enter some form data, and
submit the form.
It will POST to the server.py and if you started that one
with cvs-python (2.5a0) it will freeze on the marked line.
If you start server.py with Python 2.4, it will work fine.
--
Comment By: Irmen de Jong (irmen)
Date: 2005-02-07 09:58
Message:
Logged In: YES
user_id=129426
Yes, I'll try to make a test case for that within the next
few days.
--
Comment By: Josh Hoyt (joshhoyt)
Date: 2005-02-05 10:02
Message:
Logged In: YES
user_id=693077
Irmen, can you try to create a test case where the
cgi.FieldStorage never completes, so I can make sure that
any fix I come up with resolves it?
I will try to put together an implementation where the email
parser parses the whole multipart message.
--
Comment By: Irmen de Jong (irmen)
Date: 2005-02-05 09:06
Message:
Logged In: YES
user_id=129426
Johannes: while your patch makes my cgibug.py test case run
fine, it has 2 problems:
1- it runs much slower than the python2.4 code (pr
[ python-Bugs-1296004 ] MemoryError in httplib
Bugs item #1296004, was opened at 2005-09-20 05:14 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=1296004&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: Yue Zhang (yuezhang) Assigned to: Nobody/Anonymous (nobody) Summary: MemoryError in httplib Initial Comment: The problem from http://www.thescripts.com/forum/thread25490.html can be repeated here with python2.4.1 on WinXP. Test sample: sending about 5MB http data. It appears to be caused by line 545, httplib.py. chunk = self.fp.read(amt) It seems that reading too much from that sock causes leak. Thus trying to edit the line making it chunk = self.fp.read(min(amt,5)) the problem will be solved. //Not sure whether it was sock error for using pure sock for http won't cause this problem. If you need an example of this bug, please contact me. Also, the method in httplib is using string concatenation, which might turn slow when the strings are large. An alternative is using a temp list to cache the string sections, and join the list at last. This will be faster, with the draw back of some more memory usage. Best regards, Zhang Yue -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296004&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1256669 ] Significant memory leak with PyImport_ReloadModule
Bugs item #1256669, was opened at 2005-08-11 05:49 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256669&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Ben Held (bheld) Assigned to: Nobody/Anonymous (nobody) Summary: Significant memory leak with PyImport_ReloadModule Initial Comment: Having recently upgraded to Python 2.4, I am having a large memory leak with the following code built with VC++ 6.0: PyObject *pName, *pModule; Py_Initialize(); pName = PyString_FromString(argv[1]); pModule = PyImport_Import(pName); Py_DECREF(pName); PyObject* pModule2 = PyImport_ReloadModule(pModule); Py_DECREF(pModule2); Py_DECREF(pModule); Py_Finalize(); return 0; I get leaks of over 500 kb. I have another program which is much more complex, in which every call to PyImport_ReloadModule is leaking 200+ kb, even though I am calling Py_DECREF correctly. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-19 23:02 Message: Logged In: YES user_id=33168 I just tested with Python 2.4.2 on Linux with valgrind. It doesn't report any leaks. So this could be specific to Python 2.3.5, Windows, VC++ 6.0 or some other variation. Can you provide more info? For example, what module are you passing on the command line? Can you provide that code? What objects specifically do you think are leaking? Where were they allocated? -- Comment By: Ben Held (bheld) Date: 2005-09-14 11:09 Message: Logged In: YES user_id=1327580 This behavior is evident with Python 2.3.5 built on Windows with VC++ 6.0. -- Comment By: Collin Winter (collinwinter) Date: 2005-09-14 10:53 Message: Logged In: YES user_id=1344176 I've been unable to verify this on Linux. I've tested python versions 2.2.3, 2.3.5 and 2.4.1, all compiled with gcc 3.3.5 on Debian 3.1 under kernel 2.6.8. I used the sample program provided by Ben, modified with an infinite loop over the PyImport_ReloadModule/PyDECREF(pModule2) lines, sleeping for 1 second after every 25 iterations. I tested reloading the modules distutils, os.path, distutils.command.sdist for 300+ iterations each under each python version. No memory leak was observed. -- Comment By: Ben Held (bheld) Date: 2005-08-16 06:56 Message: Logged In: YES user_id=1327580 Boundschecker shows the leak and I have verified this by watching the process memory increase via the task manager. -- Comment By: Martin v. Löwis (loewis) Date: 2005-08-13 06:34 Message: Logged In: YES user_id=21627 How do you know there is a memory leak? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256669&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1212703 ] Python 2.5 CVS broken for HP-UX platform?
Bugs item #1212703, was opened at 2005-06-01 06:05
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212703&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Vincent Jamart (ranma)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.5 CVS broken for HP-UX platform?
Initial Comment:
While trying to compile Python 2.5 from the nighlty CVS
image, it raises the following errors on HP-UX. (OS
version= HP-UX 11.22 on ia64, compiler= aCC: HP
aC++/ANSI C B3910B A.06.00 [Aug 25 2004])
Compilation flags:
export CC=aCC
export CFLAGS="-Ae +DD64"
export LDFLAGS="+DD64"
make clean
./configure --prefix=/usr/local/python_cvs --with-cxx=aCC
(...)
creating Makefile
aCC -c -DNDEBUG -O -I. -I./Include
-DPy_BUILD_CORE -o
Modules/ccpython.o ./Modules/ccpython.cc
"/usr/include/sys/unistd.h", line 594: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline truncate(const char *a, off_t b) { return
__truncate64(a,b); }
^
"/usr/include/sys/unistd.h", line 595: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline prealloc(int a, off_t b) { return
__prealloc64(a,b); }
^
"/usr/include/sys/unistd.h", line 596: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline lockf(int a, int b, off_t c) { return
__lockf64(a,b,c); }
^
"/usr/include/sys/unistd.h", line 597: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline ftruncate(int a, off_t b) { return
__ftruncate64(a,b); }
^
"/usr/include/sys/stat.h", line 173: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline lstat __((const char *, struct stat *));
^
"./Include/pyport.h", line 612: error #2035: #error
directive: "LONG_BIT
definition appears wrong for platform (bad
gcc/glibc
config?)."
#error "LONG_BIT definition appears wrong for
platform (bad gcc/glibc
config?)."
^
1 error detected in the compilation of
"./Modules/ccpython.cc".
*** Error exit code 2
Stop.
aCC -c -DNDEBUG -O -I. -I./Include
-DPy_BUILD_CORE -o
Modules/ccpython.o ./Modules/ccpython.cc
"/usr/include/sys/unistd.h", line 594: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline truncate(const char *a, off_t b) { return
__truncate64(a,b); }
^
"/usr/include/sys/unistd.h", line 595: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline prealloc(int a, off_t b) { return
__prealloc64(a,b); }
^
"/usr/include/sys/unistd.h", line 596: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline lockf(int a, int b, off_t c) { return
__lockf64(a,b,c); }
^
"/usr/include/sys/unistd.h", line 597: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline ftruncate(int a, off_t b) { return
__ftruncate64(a,b); }
^
"/usr/include/sys/stat.h", line 173: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline lstat __((const char *, struct stat *));
^
"./Include/pyport.h", line 612: error #2035: #error
directive: "LONG_BIT
definition appears wrong for platform (bad
gcc/glibc
config?)."
#error "LONG_BIT definition appears wrong for
platform (bad gcc/glibc
config?)."
^
1 error detected in the compilation of
"./Modules/ccpython.cc".
*** Error exit code 2
Stop.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-19 23:21
Message:
Logged In: YES
user_id=33168
I think there was a fix checked in recently to address some
(hopefully all) of these issues. Does the current CVS build
on your HPUX box?
--
Comment By: Vincent Jamart (ranma)
Date: 2005-06-28 23:50
Message:
Logged In: YES
user_id=150220
This is how we managed to solve the problem here, but it's
not a clean solution:
#install script for HP-UX 11.xx
CPPFLAGS="+DD64 -I/usr/local/bzip2-1.0.3/include"
export CPPFLAGS
CC="/opt/aCC/bin/aCC -Ae +DD64"
export CC
CFLAGS="-Ae +DD64"
export CFLAGS
CXX="/opt/aCC/bin/aCC -Ae"
export CXX
CXXFLAGS="-Ae +DD64"
export CXXFLAGS
LDFLAGS="+DD64 -L/usr/local/bzip2-1.0.3/lib"
export LDFLAGS
cd dist/src
#
# Do not use the --without-gcc flag because the CC env.var.
will be
# reset to 'cc' (which do not want)
# Additionally we're not using --w
[ python-Bugs-1212703 ] Python 2.5 CVS broken for HP-UX platform?
Bugs item #1212703, was opened at 2005-06-01 23:05
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212703&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Vincent Jamart (ranma)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.5 CVS broken for HP-UX platform?
Initial Comment:
While trying to compile Python 2.5 from the nighlty CVS
image, it raises the following errors on HP-UX. (OS
version= HP-UX 11.22 on ia64, compiler= aCC: HP
aC++/ANSI C B3910B A.06.00 [Aug 25 2004])
Compilation flags:
export CC=aCC
export CFLAGS="-Ae +DD64"
export LDFLAGS="+DD64"
make clean
./configure --prefix=/usr/local/python_cvs --with-cxx=aCC
(...)
creating Makefile
aCC -c -DNDEBUG -O -I. -I./Include
-DPy_BUILD_CORE -o
Modules/ccpython.o ./Modules/ccpython.cc
"/usr/include/sys/unistd.h", line 594: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline truncate(const char *a, off_t b) { return
__truncate64(a,b); }
^
"/usr/include/sys/unistd.h", line 595: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline prealloc(int a, off_t b) { return
__prealloc64(a,b); }
^
"/usr/include/sys/unistd.h", line 596: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline lockf(int a, int b, off_t c) { return
__lockf64(a,b,c); }
^
"/usr/include/sys/unistd.h", line 597: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline ftruncate(int a, off_t b) { return
__ftruncate64(a,b); }
^
"/usr/include/sys/stat.h", line 173: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline lstat __((const char *, struct stat *));
^
"./Include/pyport.h", line 612: error #2035: #error
directive: "LONG_BIT
definition appears wrong for platform (bad
gcc/glibc
config?)."
#error "LONG_BIT definition appears wrong for
platform (bad gcc/glibc
config?)."
^
1 error detected in the compilation of
"./Modules/ccpython.cc".
*** Error exit code 2
Stop.
aCC -c -DNDEBUG -O -I. -I./Include
-DPy_BUILD_CORE -o
Modules/ccpython.o ./Modules/ccpython.cc
"/usr/include/sys/unistd.h", line 594: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline truncate(const char *a, off_t b) { return
__truncate64(a,b); }
^
"/usr/include/sys/unistd.h", line 595: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline prealloc(int a, off_t b) { return
__prealloc64(a,b); }
^
"/usr/include/sys/unistd.h", line 596: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline lockf(int a, int b, off_t c) { return
__lockf64(a,b,c); }
^
"/usr/include/sys/unistd.h", line 597: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline ftruncate(int a, off_t b) { return
__ftruncate64(a,b); }
^
"/usr/include/sys/stat.h", line 173: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline lstat __((const char *, struct stat *));
^
"./Include/pyport.h", line 612: error #2035: #error
directive: "LONG_BIT
definition appears wrong for platform (bad
gcc/glibc
config?)."
#error "LONG_BIT definition appears wrong for
platform (bad gcc/glibc
config?)."
^
1 error detected in the compilation of
"./Modules/ccpython.cc".
*** Error exit code 2
Stop.
--
>Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-09-20 16:32
Message:
Logged In: YES
user_id=29957
As far as I know, the patches contributed by Elemental
Security make current CVS HEAD work fine on ia64 HP/UX.
Please do test them, though - I think Guido put some notes
in the toplevel README about how to get the build to work.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-20 16:21
Message:
Logged In: YES
user_id=33168
I think there was a fix checked in recently to address some
(hopefully all) of these issues. Does the current CVS build
on your HPUX box?
--
Comment By: Vincent Jamart (ranma)
Date: 2005-06-29 16:50
Message:
Logged In: YES
user_id=150220
This is how we managed to solve the problem here, but it's
not a clean solution:
#install script for HP-UX 11.xx
CPPFLAGS="+DD
